[lkml]   [2001]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:53    [W:0.156 / U:0.592 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site