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 netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
