Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755731AbZICPBr (ORCPT ); Thu, 3 Sep 2009 11:01:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755020AbZICPBr (ORCPT ); Thu, 3 Sep 2009 11:01:47 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:55595 "EHLO e8.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754830AbZICPBq (ORCPT ); Thu, 3 Sep 2009 11:01:46 -0400 Date: Thu, 3 Sep 2009 08:01:39 -0700 From: "Paul E. McKenney" To: Christoph Lameter Cc: Eric Dumazet , Pekka Enberg , Zdenek Kabelac , Patrick McHardy , Robin Holt , Linux Kernel Mailing List , Jesper Dangaard Brouer , Linux Netdev List , Netfilter Developers Subject: Re: [PATCH] slub: fix slab_pad_check() Message-ID: <20090903150139.GC6761@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <4A896324.3040104@trash.net> <4A9EEF07.5070800@gmail.com> <4A9F1620.2080105@gmail.com> <84144f020909022331x2b275aa5n428f88670e0ae8bc@mail.gmail.com> <4A9F7283.1090306@gmail.com> <4A9FCDC6.3060003@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1777 Lines: 47 On Thu, Sep 03, 2009 at 01:38:50PM -0500, Christoph Lameter wrote: > On Thu, 3 Sep 2009, Eric Dumazet wrote: > > > Christoph Lameter a ?crit : > > > On Thu, 3 Sep 2009, Eric Dumazet wrote: > > > > > >> on a SLAB_DESTROY_BY_RCU cache, there is no need to try to optimize this > > >> rcu_barrier() call, unless we want superfast reboot/halt sequences... > > > > > > I stilll think that the action to quiesce rcu is something that the caller > > > of kmem_cache_destroy must take care of. > > > > Do you mean : > > > > if (kmem_cache_shrink(s) == 0) { > > rcu_barrier(); > > kmem_cache_destroy_no_rcu_barrier(s); > > } else { > > kmem_cache_destroy_with_rcu_barrier_because_SLAB_DESTROY_BY_RCU_cache(s); > > } > > > > What would be the point ? > > The above is port of slub? > > I mean that (in this case) the net subsystem would have to deal with RCU quietness > before disposing of the slab cache. There may be multiple ways of dealing > with RCU. The RCU barrier may be unnecessary for future uses. Typically > one would expect that all deferred handling of structures must be complete > for correctness before disposing of the whole cache. Which is precisely the point of the rcu_barrier(), right? Thanx, Paul > > [PATCH] slub: fix slab_pad_check() > > Acked-by: Christoph Lameter > -- > To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/