Re: Race in shrink_cache

[Andrew Morton <akpm@zip.com.au>]

Daniel Phillips wrote:
> 
> On Thursday 05 September 2002 20:51, Andrew Morton wrote:
> > Daniel Phillips wrote:
> > >
> > > ..
> > > On the other hand, if what you want is a private list that page_cache_release
> > > doesn't act on automatically, all you have to do is set the lru state to zero,
> > > leave the page count incremented and move to the private list.  You then take
> > > explicit responsibility for freeing the page or moving it back onto a
> > > mainstream lru list.
> >
> > That's the one.  Page reclaim speculatively removes a chunk (typically 32) of
> > pages from the LRU, works on them, and puts back any unfreeable ones later
> > on.
> 
> Convergent evolution.  That's exactly the same number I'm handling as a
> chunk in my rmap sharing project (backgrounded for the moment).  In this
> case, the 32 comes from the number of bits you can store in a long, and
> it conveniently happens to fall in the sweet spot of performance as well.

That's SWAP_CLUSTER_MAX.  I've never really seen a reason to change
its value.  On 4k pagesize.

The pagevecs use 16 pages.  The thinking here is that we want it to
be large enough to be efficient, but small enough so that all the
pageframes are still in L1 when we come around and hit on them again.
Plus pagevecs are placed on the stack.

> ...
> I think the extra refcount strategy is inherently stronger, and this
> is an example of why.  The other would require you to take/drop an
> extra count explicitly for your private list.

OK.  I assume you taught invalidate_inode_pages[2] about the extra ref?