[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 9 Sep 2009 07:42:38 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Christoph Lameter <cl@...ux-foundation.org>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
Pekka Enberg <penberg@...helsinki.fi>,
Zdenek Kabelac <zdenek.kabelac@...il.com>,
Patrick McHardy <kaber@...sh.net>, Robin Holt <holt@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jesper Dangaard Brouer <hawk@...x.dk>,
Linux Netdev List <netdev@...r.kernel.org>,
Netfilter Developers <netfilter-devel@...r.kernel.org>,
dhowells@...hat.com, lethal@...ux-sh.org, kernel@...tstofly.org,
mpm@...enic.com
Subject: Re: [PATCH] slub: fix slab_pad_check()
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists