From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 22 Oct 2008 12:54:30 -0700 (PDT) From: Christoph Lameter Subject: Re: SLUB defrag pull request? In-Reply-To: Message-ID: References: <1223883004.31587.15.camel@penberg-laptop> <1223883164.31587.16.camel@penberg-laptop> <200810132354.30789.nickpiggin@yahoo.com.au> <48F378C6.7030206@linux-foundation.org> <48FC9CCC.3040006@linux-foundation.org> <48FCCC72.5020202@linux-foundation.org> <48FCD7CB.4060505@linux-foundation.org> <48FCE1C4.20807@linux-foundation.org> <48FE6306.6020806@linux-foundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-linux-mm@kvack.org Return-Path: To: Miklos Szeredi Cc: penberg@cs.helsinki.fi, nickpiggin@yahoo.com.au, hugh@veritas.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org List-ID: On Wed, 22 Oct 2008, Miklos Szeredi wrote: > Why? The kmem_cache_free() doesn't touch the contents of the object, > does it? Because filesystem code may be running on other processors which may be freeing the dentry. >> Because the slab starts out with a series of objects left in a slab. It >> needs to do build a list of objects etc in a way that is independent as >> possible from the user of the slab page. It does that by locking the slab >> page so that free operations stall until the reference has been >> established. If it would not be shutting off frees then the objects could >> vanish under us. > > It doesn't matter. All we care about is that the dentry is on the > lru: it's cached but unused. Every other state (being created, > active, being freed, freed) is uninteresting. We cannot figure out that it is on the lru if we do not have a stable reference to the object. > Sure, and all that is possible without doing this messy 2 phase thing. > Unless I'm still missing something obvious... Obviously one cannot free or handle an object that may be concurrently freed on another processor. -- 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