Re: [PATCH RFC -tip 0/4] v3 RCU cleanups and simplifiedpreemptable RCU

From: Paul E. McKenney
Date: Mon Aug 24 2009 - 11:59:21 EST

On Mon, Aug 24, 2009 at 09:21:59AM +0200, Peter Zijlstra wrote:
> On Sat, 2009-08-22 at 13:52 -0700, Paul E. McKenney wrote:
> >
> > o Rename variables and functions so that RCU-sched is an
> > underlying definition, along with RCU-bh and (when so
> > configured) RCU-preempt. RCU then maps to either RCU-sched
> > or RCU-preempt, depending on configuration.
> Nice, but we're not quite there yet it seems, since RCU-preempt isn't
> available outside of TREE_PREEMPT_RCU afaiks.
> That is, I'm still hoping for the day that generic code can do:
> rcu_preempt_read_lock();
> call_rcu_preempt(&my_rcu_thing);
> rcu_preempt_read_unlock();
> And have it work like expected, this would, I think, remove much of the
> need for SRCU.

!CONFIG_PREEMPT will imply CONFIG_TREE_RCU. This will reduce the
number of combinations in need of testing. So then the question is
"what does call_rcu_preempt() mean in !CONFIG_PREEMPT"?

If we permit things like mutex_lock(), we have the possibility of
indefinitely extended RCU read-side critical sections, which leads us to:

> The thing I've talked about earlier is an extension of this where you
> can create multiple RCU domains along the lines of:
> struct rcu_preempt_domain my_domain;
> rcu_preempt_init(&my_domain);
> and
> rcu_preempt_read_lock(&my_domain);
> call_rcu_preempt(&my_domain, &my_rcu_head);
> rcu_preempt_read_unlock(&my_domain);

This is in fact what SRCU does. Of course, it also requires
that the return value from rcu_preempt_read_lock() be passed into
rcu_preempt_read_unlock() (AKA srcu_read_lock() and srcu_read_unlock()),
in order to handle the case where there are a number of nested SRCU
read-side critical sections with different domains. I suppose that we
could instead dynamically allocate space for this information, but...

> Which would allow you to create smaller RCU domains for when you want
> faster grace periods due to less interference of other rcu users.

The other thing in -tip for this purpose is synchronize_rcu_expedited().

> Anyway, enough rambling, the patch-set does look very nice, and if time
> permits I'll try and go through the preempt-tree-rcu thing.

I would very much appreciate that!!! My next patch set (hopefully later
today Pacific time) will fix CPU hotplug for the single-node-tree case,
with full support later this week.

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