Messages in this thread | | | Date | Sun, 20 May 2001 11:47:33 +0200 (CEST) | From | Mike Galbraith <> | Subject | Re: [RFC][PATCH] Re: Linux 2.4.4-ac10 |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |