Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Mike Galbraith <mikeg@wen-online.de>]

On Sun, 20 May 2001, Rik van Riel wrote:

> On Sun, 20 May 2001, Mike Galbraith wrote:
>
> > You're right.  It should never dump too much data at once.  OTOH, if
> > those cleaned pages are really old (front of reclaim list), there's no
> > value in keeping them either.  Maybe there should be a slow bleed for
> > mostly idle or lightly loaded conditions.
>
> If you don't think it's worthwhile keeping the oldest pages
> in memory around, please hand me your excess DIMMS ;)

You're welcome to the data in any of them :)  The hardware I keep.

> Remember that inactive_clean pages are always immediately
> reclaimable by __alloc_pages(), if you measured a performance
> difference by freeing pages in a different way I'm pretty sure
> it's a side effect of something else.  What that something
> else is I'm curious to find out, but I'm pretty convinced that
> throwing away data early isn't the way to go.

OK.  I'm getting a little distracted by thinking about the locking
and some latency comments I've heard various gurus make.  I should
probably stick to thinking about/measuring throughput.. much easier.

but ;-)

Looking at the locking and trying to think SMP (grunt) though, I
don't like the thought of taking two locks for each page until
kreclaimd gets a chance to run.  One of those locks is the
pagecache_lock, and that makes me think it'd be better to just
reclaim a block if I have to reclaim at all.  At that point, the
chances of needing to lock the pagecache soon again are about
100%.  The data in that block is toast anyway.  A big hairy SMP
box has to feel reclaim_page(). (they probably feel the zone lock
too.. probably would like to allocate blocks)

	-Mike

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/