Re: [RFC][PATCH] dcache and rmap
From: Ed Tomlinson <hidden>
Date: 2002-05-13 11:50:03
Hi, I did something similiar in the patch I posted under the subject: [RFC][PATCH] cache shrinking via page age Only I used the same method we now use to shrink caches but triggered them using page aging, and at the same time making the trigger cache specific. Another though I had was to put the 'freeable' slab pages onto the inactive clean list and reclaim them when they reach the head of the list. It gets a little tricky since slabs can contain multiple pages... Before trying this I want to see how well what I have posted works. Ed Tomlinson On May 13, 2002 07:07 am, Nikita Danilov wrote:
William Lee Irwin III writes: > At some point in the past, I wrote: > >> In short, I don't think you went far enough. How do you feel about > >> GFP_SPECULATIVE (a.k.a. GFP_DONT_TRY_TOO_HARD), cache priorities and > >> cache shrinking drivers? > > On Tue, May 07, 2002 at 07:41:52AM -0400, Ed Tomlinson wrote: > > Think I will sprinkle slab.c with a printk or two to see if we detect > > when it's allocations are eating other caches. If this works we > > should be able to let the vm know when to shrink the slab cache and to > > let it know which caches need shrinking (ie shrink_caches becomes a > > 'driver' to shrink the dcache/icache family. kmem_cache_reap being > > the generic 'driver') Thanks for the feedback and interesting idea, > > Well, the trick is kmem_cache_reap() doesn't know how to prune > references to things within the cache like prune_dcache() does. It is > in essence its own cache in front of another cache for allocations. I'm > not sure making kmem_cache_reap() trigger reaping of the caches it's > parked in front of is a great idea. It seems that it would go the other > direction: reaping a cache parked in front of a slab would want to call > kmem_cache_reap() sometime afterward (so the memory is actually > reclaimed instead of sitting in the slab cache). IIRC the VM actually > does this at some point after calling the assorted cache shrink > functions. kmem_cache_reap() may well be needed in contexts where the > caches are doing fine jobs of keeping their space under control or > shrinking themselves just fine, without intervention from outside > callers. I remember Linus once mentioned an idea that slab pages should have ->writepage() that triggers shrink of the front-end cache. Along this way, VM would just manage one big cache---physical memory. > Cheers, > Bill Nikita.
-- 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/