[ale] Can someone help me understand memory usage?

[Joseph A Knapka]

Unknown wrote:
> 
> Geoffrey wrote:
> 
> > Jeff Hubbs wrote:
> >
> >
> >> Yeah, but 2.4 kernels are "greedier" than 2.2 and before.  As I
> >> understand it, you can no longer view gobs and gobs of free RAM as a
> >> sign of system health.  Rather, the OS stakes out big swaths of
> >> otherwise unused RAM and hangs onto it.  And, eventually, it will
> >> start filling up swap.  However, this is not so much a sign of
> >> impending meltdown as the kernel going, "hm, here's a section of RAM
> >> that hasn't been used in hours; I'm throwing it to the swap file."
> >
> >
> > I don't know how 2.4 kernels have changed, but either I don't understand
> > what you've just said, or I think it's a poor direction to head.  The
> > LAST thing the OS should do is use swap.  It should look for unused
> > memory and take advantage of it.  Using swap is kinda like you've got a
> > bus load of folks and their's no more room, so you take the bicycle off
> > the roof rack and hand it to the next guy trying to get on the bus. AND,
> > the bus then stays behind the guy on the bike.  Point being, using swap
> > slows down everything.
> >
> > Did I misunderstand your statement, or are you saying the OS will use up
> > memory quickly because of the allocated chunk sizes, therefore hit the
> > swap much sooner than it used to???
> >
> >
> 
> Well, you're kind of pushing me to the wall as regards my knowledge and
> explanatory power...but here goes! :-)
> 
> It's as though 2.4 kernels have done away with this notion that you
> should have as much free RAM as possible at any given moment.  Instead,
> the kernel is eating into free RAM not because it needs to but because
> it wants to.  Perhaps the impetus here is one of planning ahead:  The
> kernel needn't take steps to grab more memory when it suddenly needs it
> IF it's already grabbed it.  In other words, VM OS memory management
> seems to have historically been predicated on the fear that someone was
> going to steal RAM out of your machine at any moment.  Modern Linux
> kernels seem to act like, if you gave it half a gig, it's gonna act as
> though it's going to stay in the box.  It also seems to act as though it
> does not harm you, the user, if it has taken up a total 426 of 512MB
> even if it's not really doing anything (which it doesn't).

Clarification:

The kernel does not acquire RAM for no reason whatsoever.
However, when it *does* acquire RAM for a particular
purpose, that RAM will tend to remain in use for that
same purpose, unless memory pressure forces it to be
reclaimed.

In the course of running a program, we allocate memory
in basically four ways: (1) The program's code is paged
in from the executabl file on disk; (2) the program
allocates "free" memory and uses it (note that if a
program allocates memory but never uses it, that
memory will never physically be allocated); (3) the
process may map some disk files into its memory
space; (4) the kernel may allocate small amounts
of memory for internal use on behalf of a process.

That memory will be used by the process to
varying degrees. Memory that isn't used regularly will
be classified as "inactive", and when the kernel needs
some more memory, it will use inactive pages, unless
copious genuinely-free pages are available. These
inactive pages are the "cache".

For all but case (4), the memory involved is associated
with a disk file (a memory-mapped disk file for (1)&(3),
and a swap file for (2)). One big question a VM designer
has to answer is, "When should I write those pages
out to disk and free the associated memory?" The
right answer is, basically, "never", because if the
pages are needed again you'd have to go out to the
disk to get them, whereas if they're still in RAM
you just look them up and use them. Of course, sometimes
you need some fresh RAM, and in that case you must
write out some cache pages, but the kernel does
its level best to ensure that that happens as
rarely as possible.

The upshot of all this is that once a page has been
used for a particular purpose (say, it's the 53rd
text page of the Emacs executable file), the kernel
will, unless things get crowded memory-wise, continue
to use that page for the same purpose, rather
than freeing it. So you start Emacs, some code
touches page 53, page 53 gets loaded from disk,
you finish your task and exit emacs. Page 53
(as well as every other executable page that
was loaded during your editing session) stays in 
the cache, and the next time someone runs Emacs,
the kernel doesn't have to touch the disk at
all, unless memory pressure has forced some
of those pages out of the cache in the meantime.

The result is that under normal conditions, the
cache never shrinks. That's why you'll see the
"Cache" column on vmstat staying constant or
growning, even on a lightly-loaded machine.

Cheers,

-- Joe
  Using open-source software: free.
  Pissing Bill Gates off: priceless.

---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.