Hi!

On Mon, 15 Nov 2004, Thor Lancelot Simon wrote:

> On Mon, Nov 15, 2004 at 02:04:02PM +0200, Arto Selonen wrote:

> > 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

Thanks for the excellent answer. Makes code reading a lot easier when
I know what I am supposed to be looking at. :)

> 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"?

Well, page daemon is asking for something back, with the buf_drain() call
after page scanning etc. However, in my case bufmem was >17,000 *pages*
(I chose to talk in pages instead of bytes, to have smaller numbers)
over bufmem_hiwater, and that buf_drain() call from page daemon only
asks for 20-80 pages per page daemon invocation (freetarg-free). It'll
take a while to get below hiwater mark that way. Of course, I could be wrong,
there could be other ways to free buffer cache memory, etc.

My main concerns were that bufmem was getting over hiwater mark (it came
as a surprise, but it also makes sense), and mostly, that page daemon
does not have access to that overhead *before* scanning. And if I'm
not mistaken, it will not ask much back even after messing with the
page queues. Sure, even with ~30 pages per invocation, it will eventually
get it all back (assuming that there is no way for buffer cache to
keep on growing between page daemon invocations, as the growth is not
limited the same way as memory re-claiming through buf_drain()).
And all the while buffer cache is *slowly* being reduced to below
hiwater usage, page daemon keeps on sending useful pages to swap.
Thus, the buffer cache memory is not re-claimed in a *timely* manner.
(Or that is my assumption, as I don't know any better; it is easy to
make such claims without factual background knowledge, so forgive me
if I'm wrong).

I'll continue my explorations in the land of NetBSD source code...


Artsi
-- 
#######======------  http://www.selonen.org/arto/  --------========########
Everstinkuja 5 B 35                               Don't mind doing it.
FIN-02600 Espoo        arto@selonen.org         Don't mind not doing it.
Finland              tel +358 50 560 4826     Don't know anything about it.