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 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/
