From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 7 May 2002 05:57:12 -0700 From: William Lee Irwin III Subject: Re: [RFC][PATCH] dcache and rmap Message-ID: <20020507125712.GM15756@holomorphy.com> References: <200205052117.16268.tomlins@cam.org> <20020507014414.GL15756@holomorphy.com> <200205070741.52896.tomlins@cam.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: brief message Content-Disposition: inline In-Reply-To: <200205070741.52896.tomlins@cam.org> Sender: owner-linux-mm@kvack.org Return-Path: To: Ed Tomlinson Cc: linux-mm@kvack.org List-ID: 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. Cheers, Bill -- 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/