On Mon, Aug 24, 2009 at 09:21:59AM +0200, Peter Zijlstra wrote:
quoted text
> 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.

Longer term, CONFIG_PREEMPT will imply CONFIG_TREE_PREEMPT_RCU and
!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:

quoted text
> 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...

quoted text
> 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().

quoted text
> 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
--
unsubscribe notice
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/