From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <43419686.60600@colorfullife.com> Date: Mon, 03 Oct 2005 22:37:26 +0200 From: Manfred Spraul MIME-Version: 1.0 Subject: Re: [PATCH] per-page SLAB freeing (only dcache for now) References: <20050930193754.GB16812@xeon.cnet> <20051001215254.GA19736@xeon.cnet> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Marcelo , linux-mm@kvack.org, akpm@osdl.org, dgc@sgi.com, dipankar@in.ibm.com, mbligh@mbligh.org List-ID: Christoph Lameter wrote: >On Sat, 1 Oct 2005, Marcelo wrote: > > > >>I thought about having a mini-API for this such as "struct slab_reclaim_ops" >>implemented by each reclaimable cache, invoked by a generic SLAB function. >> >> >> Which functions would be needed? - lock_cache(): No more alive/dead changes - objp_is_alive() - objp_is_killable() - objp_kill() I think it would be simpler if the caller must mark the objects as alive/dead before/after calling kmem_cache_alloc/free: I don't think it's a good idea to add special case code and branches to the normal kmem_cache_alloc codepath. And especially: It would mean that kmem_cache_alloc must perform a slab lookup in each alloc call, this could be slow. The slab users could store the alive status somewhere in the object. And they could set the flag early, e.g. disable alive as soon as an object is put on the rcu aging list. The tricky part is lock_cache: is it actually possible to really lock the dentry cache, or could RCU cause changes at any time. -- Manfred -- 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/ . Don't email: email@kvack.org