Re: [rfc] possible page manipulation simplifications?

[Nick Piggin <npiggin@suse.de>]

On Mon, Dec 04, 2006 at 02:40:05PM +0000, Mel Gorman wrote:
> On (02/12/06 13:15), Nick Piggin didst pronounce:
> > Hi,
> > 
> > While working in this area, I noticed a few things we do that may not
> > have a positive payoff under the most common conditions. Untested yet,
> > and probably needs a bit of instrumentation, but it saves about half a
> > K of code, lots of branches, and makes things look nicer. Any thoughts?
> > 
> > Quite a bit of code is used in maintaining these "cached pages" that are
> > probably pretty unlikely to get used.
> > 
> 
> I think you might be leaking now though. More comments below.
> 
> > Also, buffered write path (and others) uses its own LRU pagevec when we should
> > be just using the per-CPU LRU pagevec (which will cut down on both data and
> > code size cacheline footprint).
> > 
> 
> Splitting the patch into two could be nice but it's grand for the
> moment.

Hi Mel,

I think you're right about the leakage, thanks for catching it.

As far as allocating pages twice is concerned, I *strongly* believe
it is the wrong tradeoff to fix this with a "cached_page" because we
have to hit 2 reasonably rare races.

Firstly, we must find no pagecache exists, then we discover a page
has been installed after allocating. This will be rare for most
workloads, but lets say that it comes up in a few because page alloc
may sleep (a busy file server might have several processes reading
the same file, triggering this race in the write path would be even
less common).

However supposing this race is triggered, then we *also* need to
fail the page lookup a few instructions after a similar operation
has succeeded!

Thanks, will post an updated and properly tested version in a while.

--
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-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>