Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Mon, Sep 09, 2013 at 09:55:11AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 06:46:05 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> 
> 
> > > Also, if its per-task, why don't we have this in the task struct? The
> > > current scheme makes the context switch more expensive -- is this the
> > > right trade-off?
> > 
> > There are constraints based on the task, but RCU really is
> > paying attention to CPUs, not than tasks.  (With the exception of
> > TREE_PREEMPT_RCU, which does keep lists of tasks that it has to pay
> > attention to, namely those that have been preempted within their current
> > RCU read-side critical section.)
> 
> Conceptually wise, RCU keeps track of task state, not CPU state. In all
> your diagrams in your presentations, where you talk about grace periods
> and quiescent states, you show tasks, not CPUs.
> 
> RCU's implementation is based on CPUs, and only when rcu_read_lock()
> prevents preemption. As you stated above, TREE_PREEMPT_RCU needs to
> keep track of tasks.

Actually, in TINY_RCU and TREE_RCU, preemption is disabled to begin
with, so that rcu_read_lock() doesn't need to do anything.  I left
the preempt_disable() in rcu_read_lock() and the preempt_enable() in
rcu_read_unlock() in case we ever have need to run either TINY_RCU or
TREE_RCU in a CONFIG_PREEPT=y kernel.

That said, TREE_PREEMPT_RCU's implementation does track tasks sometimes,
but only in the (hopefully) uncommon case where an RCU read-side critical
section is preempted.

However, the API we are arguing about is deep within the implementation.
It is not at the level of rcu_read_lock().  It is something that should
not have that many invocations -- after all, the things using it are
binding themselves unusually close to RCU.

> I think you are too deep into the implementation, that you are
> forgetting the concept that you created :-)

Like I said before (though admittedly after you wrote the above), the
implementation came first and the concepts much later.  ;-)

							Thanx, Paul