Messages in this thread |  | | From | Daniel Phillips <> | Subject | Re: Race in shrink_cache | Date | Thu, 5 Sep 2002 22:00:14 +0200 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |