On Mon, Nov 15, 2004 at 02:04:02PM +0200, Arto Selonen wrote:
> 
> Since lotsfree looks fairly simple, I'm assuming that the extra growth
> is allowed by allocbuf(), as it simply *tries* to trim the bufmem usage
> when hiwater mark is reached. So, presumably it could fail to enforce the
> hiwater mark? It looks like buf_canrelease by design can return 0,
> if there is no low memory condition (free pages above target free),
> and there is nothing on AGE list (part I don't quite understand).

The AGE list is essentially a delayed-free list; it is used to avoid
freeing buffers in interrupt context.  Sometimes the filesystem or
buffer cache code knows that the contents of a given buffer will never
again be needed (e.g. metadata for a deleted file).  We would like to
free this memory back to the system as quickly as possible.  But we
might be in interrupt context, where it is not safe to make arbitrary
manipulations of the VM system and pool data structures.

So, we put such buffers on the AGE list; such buffers are preferentially
recycled, with the special rule that whenever anyone asks us for memory,
we free the _entire_ AGE list immediately (and then anything else that
is required).

After a lot of pain and suffering, I am pretty darned sure that with the
exception of buffers on which I/O is currently pending, and buffers
locked by LFS (which is a special case of "buffers on which I/O is
currently pending), if anything else in the system asks for memory
the buffer cache _will_ give it back.  The question would seem to be,
in your case: "why isn't the buffer cache being asked to give memory
back"?

Thor