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

[Steven Rostedt]

On Mon, 9 Sep 2013 09:17:08 -0700
"Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote:

> On Mon, Sep 09, 2013 at 10:16:29AM -0400, Steven Rostedt wrote:
> > On Mon, 9 Sep 2013 06:56:56 -0700
> > "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
> > 
> > 
> > > Indeed, there is on ongoing naming debate as well.  About the only point
> > > of agreement thus far is that the current names are inadequate. ;-)
> > > 
> > > My current feeling is that rcu_is_cpu_idle() should be called
> > > rcu_watching_this_cpu() and what is called rcu_watching_this_cpu()
> > > in my local tree should be called __rcu_watching_this_cpu().
> > 
> > I disagree. Then it would not make sense if we take a return value of
> > "__rcu_watching_this_cpu()" and use it on another CPU to make other
> > decisions for that other CPU.
> 
> Frederic and I both went through why this works.


My concern is people stumbling over why preemption can be enabled here?

If it must *always* be called with preemption disabled (no
rcu_watching_this_cpu() version that disables preemption for you) then
I would be OK with it.

The problem I'm having is, anything that uses "this_cpu()" can cause
problems with understanding the code, because the first thing I think
is "if we get the result for 'this_cpu', it may not be 'this_cpu' when
I use it".

> 
> > I still think we are confusing concepts with implementation. Yes, the
> > RCU implementation tracks CPU state, but the concept is still based on
> > the task.
> 
> You keep asserting this, but I am not seeing it.  Sure, you can argue
> that grace periods are based on tasks as well as or instead of CPUs.
> But I am not convinced that it helps at the dynticks interface.
> 
> > But you are right, with dynamic ticks, things get a little more
> > complex, as dynamic ticks is a CPU state, not a task state, as it can
> > be something other than the running task that changes the state
> > (another task gets scheduled on that CPU).
> > 
> > But I think we are coupling RCU a bit too much with dynamic ticks here.
> > Maybe we need to take a step back to visualize concepts again.
> 
> If we don't couple it pretty tightly, it won't work.  And whatever we
> want to call this thing that determines what RCU is paying attention to
> has to be at the implementation level.  For things like rcu_read_lock()
> and synchronize_rcu(), yes, the task view is important -- and in recent
> documentation is the POV I use.
> 
> > The state of being in dynamic tick mode is determined by what a task or
> > tasks are doing on the CPU. One of those things is if the task needs to
> > be tracked by RCU. And here, is where I think we are getting our
> > confusion from. The dynamic tick state needs to check if the running
> > task is requiring RCU or not, and thus we ask for "is rcu needed on
> > this CPU?" when the real question is "is the task running on this CPU
> > requiring RCU?"
> > 
> > Again, if we keep things in a conceptual mode, and not look too much at
> > the implementation details, I think more people will understand what's
> > going on. Especially those that don't know why something was
> > implemented the way it was.
> 
> All this aside, do you have a name you are nominating?

Something that doesn't specify "this_cpu" or "cpu" if the result can be
used on another cpu correctly.

"rcu_is_ignored()" or "rcu_is_not_active()", "rcu_is_watching_you()"

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/