Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753371AbZIIOmk (ORCPT ); Wed, 9 Sep 2009 10:42:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753308AbZIIOmj (ORCPT ); Wed, 9 Sep 2009 10:42:39 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]:32956 "EHLO e2.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752296AbZIIOmi (ORCPT ); Wed, 9 Sep 2009 10:42:38 -0400 Date: Wed, 9 Sep 2009 07:42:38 -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 , dhowells@redhat.com, lethal@linux-sh.org, kernel@wantstofly.org, mpm@selenic.com Subject: Re: [PATCH] slub: fix slab_pad_check() Message-ID: <20090909144238.GA6749@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <4AA00400.1030005@gmail.com> <20090903231757.GP6761@linux.vnet.ibm.com> <20090904204335.GG6751@linux.vnet.ibm.com> <20090908222036.GM6753@linux.vnet.ibm.com> <20090908225937.GO6753@linux.vnet.ibm.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: 1333 Lines: 27 On Wed, Sep 09, 2009 at 10:04:20AM -0400, Christoph Lameter wrote: > On Tue, 8 Sep 2009, Paul E. McKenney wrote: > > > > No direct request but I have seen the network developers discover these > > > features and their caching benefits over the last year. It is likely that > > > they will try to push it into more components of the net subsystem. > > > > So if they push it far enough, they might well decide that they need > > a SLAB_DESTROY_BY_RCU_BH, for example. Looks like seven bits left, > > so unless I am missing something, should not be a huge problem should > > this need arise. > > I'd rather have the call_rcu in the slabs replaced by a function that > can be set by the user. Then we can remove all rcu barriers from the code > and the slabs could be used with any type of rcu functionality. If the embedded guys are OK with an additional pointer in the slab data structure, I have no objection to this approach. I am assuming that we would use the usual ops-style structure full of pointers to functions in order to avoid a pair of extra pointers. Thanx, Paul -- 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/