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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
