Re: Race in shrink_cache

[Daniel Phillips <phillips@arcor.de>]

On Thursday 05 September 2002 21:22, Andrew Morton wrote:
> 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?

Yes, all the magic tests have been replaced with versions that depend on
the LRU_PLUS_CACHE define (1 or 2).  As a side effect, this lets you find
all the places that care about this with a simple grep, so I'd be inclined
to leave the symbol in, even after we decide which setting we prefer.

-- 
Daniel