Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!decwrl!shelby!neon!Gang-of-Four!weening
From: weening@Gang-of-Four.Stanford.EDU (Joe Weening)
Newsgroups: comp.sys.alliant
Subject: Re: Controlling free memory
Message-ID: <1990Mar10.035438.18204@Neon.Stanford.EDU>
Date: 10 Mar 90 03:54:38 GMT
References: <1990Mar9.174826.11922@Neon.Stanford.EDU> <4843@paperboy.OSF.ORG>
Sender: root@Neon.Stanford.EDU (System PRIVILEGED Account)
Organization: Computer Science Department, Stanford University
Lines: 39
In-Reply-To: collins@osf.org's message of 9 Mar 90 22:41:11 GMT

In article <4843@paperboy.OSF.ORG> collins@osf.org (Jeff Collins) writes:

   That number indicates the amount of free memory.  If there is any free
   memory and it is needed by a program it will be allocated.  In other words,
   if the memory demand on you system was sufficient, then that number
   would go down.  Your next question might be "does my kernel start paging
   to keep that number at 5MB or higher?"  The answer is no.  The kernel is
   very smart about how it allocates physical memory and when it starts
   paging.

Saying that the kernel is "very smart" doesn't convince me at all.
Perhaps you could describe the algorithms used by the Alliant kernel.
It certainly doesn't always act reasonably for us.

   Be satisfied with the fact that your user communitee is not
   demanding more than, on average, 43MB of physical memory.

Our user community (not "communitee") demands quite a bit more than
43MB of physical memory.  Actually our user processes demand virtual
memory, and the kernel decides how to allocate physical memory.  But
we're often running several Lisp processes, each of which would get a
running set size of over 20MB if it was running alone.  This along
with the xterm, emacs, csh, etc. processes drives the usage way above
our actual physical memory.

   If the user communitee needed more than this it would be allocated,
   and the number would go below 5MB free.

Sorry, you're making assumptions about our environment and about what
is happening that are simply not correct.

Our free memory sometimes does go below 5MB, but never very close to
zero.  The memory usage of large processes often causes swapping (not
paging) of other processes, which then have to fight their way back
into memory when they become active (like responding to a keystroke).
This happens while there is plenty of free memory available.
--
Joe Weening                                Computer Science Dept.
weening@Gang-of-Four.Stanford.EDU          Stanford University