Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755664AbZICOoM (ORCPT ); Thu, 3 Sep 2009 10:44:12 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755456AbZICOoM (ORCPT ); Thu, 3 Sep 2009 10:44:12 -0400 Received: from smtp2.ultrahosting.com ([74.213.174.253]:41093 "EHLO smtp.ultrahosting.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754575AbZICOoK (ORCPT ); Thu, 3 Sep 2009 10:44:10 -0400 Date: Thu, 3 Sep 2009 13:38:50 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@V090114053VZO-1 To: Eric Dumazet cc: Pekka Enberg , Zdenek Kabelac , Patrick McHardy , Robin Holt , Linux Kernel Mailing List , Jesper Dangaard Brouer , Linux Netdev List , Netfilter Developers , paulmck@linux.vnet.ibm.com Subject: Re: [PATCH] slub: fix slab_pad_check() In-Reply-To: <4A9FCDC6.3060003@gmail.com> Message-ID: References: <4A87CE60.4020506@gmail.com> <4A896324.3040104@trash.net> <4A9EEF07.5070800@gmail.com> <4A9F1620.2080105@gmail.com> <84144f020909022331x2b275aa5n428f88670e0ae8bc@mail.gmail.com> <4A9F7283.1090306@gmail.com> <4A9FCDC6.3060003@gmail.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1360 Lines: 38 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. > [PATCH] slub: fix slab_pad_check() Acked-by: Christoph Lameter -- 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/