From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 22 Oct 2008 13:59:54 -0700 (PDT) From: Christoph Lameter Subject: Re: SLUB defrag pull request? In-Reply-To: Message-ID: References: <1223883004.31587.15.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: >> That is the impression that I got from you too. I have listed the options >> to get a reliable reference to an object and you seem to just skip over >> it. > > Because you don't _need_ a reliable reference to access the contents > of the dentry. The dentry is still there after being freed, as long > as the underlying slab is there and isn't being reused for some other > purpose. But you can easily ensure that from the slab code. With the two callbacks that I described that would take the global lock? That was already discussed before. Please read! It does not scale and the lock would have to be acquired before objects in a slab page are scanned and handled in any way. Without that locking any other processor can go into reclaim and start evicting the dentries that we are operating upon. Freeing in the slab sense means that a kfree ran to get rid of the object. -- 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