Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758796AbYJVVBS (ORCPT ); Wed, 22 Oct 2008 17:01:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753075AbYJVVBD (ORCPT ); Wed, 22 Oct 2008 17:01:03 -0400 Received: from nlpi053.sbcis.sbc.com ([207.115.36.82]:51887 "EHLO nlpi053.prodigy.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752357AbYJVVBC (ORCPT ); Wed, 22 Oct 2008 17:01:02 -0400 Date: Wed, 22 Oct 2008 13:59:54 -0700 (PDT) From: Christoph Lameter X-X-Sender: cl@quilx.com 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 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 X-Spam-Score: -2.5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1175 Lines: 26 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/