Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758892AbYJVTze (ORCPT ); Wed, 22 Oct 2008 15:55:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755896AbYJVTzH (ORCPT ); Wed, 22 Oct 2008 15:55:07 -0400 Received: from nlpi053.sbcis.sbc.com ([207.115.36.82]:40840 "EHLO nlpi053.prodigy.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758018AbYJVTzF (ORCPT ); Wed, 22 Oct 2008 15:55:05 -0400 Date: Wed, 22 Oct 2008 12:54:30 -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> <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 X-Spam-Score: -2.5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1364 Lines: 33 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 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/