On Mon, Sep 09, 2013 at 09:21:42AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 15:08:53 +0200
> Frederic Weisbecker <fweis...@gmail.com> wrote:
>
> > On Mon, Sep 09, 2013 at 08:55:04AM -0400, Steven Rostedt wrote:
>
> > > From reading the context a bit more, it seems that the per cpu value is
> > > more a "per task" value that happens to be using per cpu variables, and
> > > changes on context switches. Is that correct?
> >
> > Yeah that's probably what confuse so many people. It's indeed at the same
> > time a task state and a per cpu state.
>
> Especially since the function name itself is "rcu_is_cpu_idle()" which
> tells you it's a cpu state, and not a task state. Why would you care in
> RCU if CPU 1 is idle if you are on CPU 2? The name should be changed.
I could call it rcu_watching_this_cpu(), and rename the current
rcu_watching_this_cpu() to __rcu_watching_this_cpu().
It should be possible to make a straightforward comment that helps.
I will let Frederic take first crack at it.
> > Pretty much like tsk->ti->preempt_count that people now try to implement
> > through a per cpu value.
>
> Actually, preempt_count is more a CPU state than a task state. When
> preempt_count is set, that CPU can not schedule out the current task.
> It really has nothing to do with the task itself. It's the CPU that
> can't do something. Preempt count should never traverse with a task
> from one CPU to another.
And this is similar to what is happening with rcu_is_cpu_idle(). The
rcu_dynticks.dynticks per-CPU variable cannot transition between zero
and non-zero while a given non-idle task is running. So what about
the idle tasks? Well, they run with preemption disabled, so they can
safely access per-CPU variables.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
