Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!patton.wpd.sgi.com!jmb
From: jmb@patton.wpd.sgi.com (Jim Barton)
Newsgroups: comp.sys.sgi
Subject: Re: Free memory seems low
Message-ID: <1991Jan30.160150.6467@odin.corp.sgi.com>
Date: 30 Jan 91 16:01:50 GMT
References: <1991Jan24.155817.22594@rice.edu> <1991Jan29.022252.2860@odin.corp.sgi.com> <mg.665224839@godzilla>
Sender: news@odin.corp.sgi.com (Net News)
Reply-To: jmb@patton.wpd.sgi.com (Jim Barton)
Organization: Silicon Graphics Inc.
Lines: 29

Having started life a long time ago as a kernel hacker, memory that
isn't allocated to the kernel in some way is "free", i.e., I (the
kernel) can go get it and use it for something else. So, I automatically
calculated the available space as that the kernel wasn't using for
something or hadn't been locked down.

It's quite correct that the memory is full of data and text for running
programs. Most of the time, alot of that memory isn't in use, since
daemons sleep most of the time, biod and nfsd daemons always execute in
the kernel, and working sets are in general much smaller than the actual
program size (there, I did it again. "in use" means that some program
has executed instructions or touched data on that page in the recent past).

The kernel doesn't bother with these pages unless it needs the memory
for something else. "Mr. VM" Mike Thompson says that one thing he does
to find out how much memory is really "free" is to run a program which
simply touches data larger than physical memory. This causes most other
pages to be paged out and allocated to that program. The program then
exits, and if you look quick before any daemons or window managers or
other things run than that memory will be totally "free".

In general, the kernel doesn't run the paging daemon (called 'vhand' in
a ps listing) unless memory gets tight, and it quits when a certain
minimum number of pages have been made available. This avoids any paging
system overhead unless you really need to page.

-- Jim Barton
   Silicon Graphics Computer Systems
   jmb@sgi.com