Messages in this thread | | | Date | Mon, 9 Sep 2013 06:48:57 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section? |
| |
On Mon, Sep 09, 2013 at 09:29:17AM -0400, Steven Rostedt wrote: > On Mon, 9 Sep 2013 09:21:42 -0400 > Steven Rostedt <rostedt@goodmis.org> wrote: > > > > 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. > > > 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. > > I'll take this a step further. Here's a simple rule to determine if > something is a task state or a CPU state. > > If the state migrates with a task from one CPU to another, it's a task > state. > > If the state never leaves a CPU with a task, then it's a CPU state. > > According to the above rules, rcu_is_cpu_idle() is a task state, and > really should be in task_struct, and preempt_count is a CPU state, and > should be a per_cpu variable.
Ahem. The rcu_dynticks.dynticks field really is per-CPU state: it is tracking whether or not RCU is paying attention to the corresponding -CPU-, not to any particular task. When RCU wants to track tasks, it does so with the blkd_tasks field of the rcu_node structure.
Thanx, Paul
> I think the reason preempt_count never was a per cpu variable, is that > having it in the stack (thread info) made it easier to test in assembly > than having to grab the per cpu info. But I believe it's easier to grab > per cpu info in assembly today than it once was, which is why there is > a push to move preempt_count to per_cpu where it truly belongs. > > -- Steve >
| |