From: Paul E. McKenney on
On Thu, Apr 01, 2010 at 06:36:14PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-04-01 at 09:15 -0700, Paul E. McKenney wrote:
> > > I don't understand. I thought the problem was that the locks were
> > > taken inside an rcu critical section; switching to srcu would fix
> > > that. But how is call_rcu_preempt() related? Grepping a bit, what
> > > is call_rcu_preempt()? my tree doesn't have it.
> >
> > I believe that Peter is referring to the RCU implementation you get
> > with CONFIG_TREE_PREEMPT_RCU, which currently depends on CONFIG_PREEMPT.
> > The other implementation is CONFIG_TREE_RCU, which is usually called
> > "classic RCU".
> Right, so I've been nudging Paul a while to make it so that we always
> have preemptible rcu available and that only the default interface
> switches between sched/classic and preempt.
> Currently we already have:
> call_rcu_sched()
> call_rcu_bh()
> call_rcu() (depends on CONFIG_PREEMPT_RCU)
> I'm saying it would be nice to also have:
> call_rcu_preempt()

And, given the !CONFIG_PREEMPT issue, along with the issue of
sleeping forever in RCU read-side critical sections, my counteroffer
has been to integrate SRCU into the treercu (and of course the
tinyrcu) implementations, thus getting roughly the same performance

Delivering on this counteroffer has proven to be another kettle of fish,
although I am making some progress. It will be several months, best case.

Thanx, Paul
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)
More majordomo info at
Please read the FAQ at