Messages in this thread | | | Date | Tue, 5 Aug 2014 08:47:55 +0800 | From | Lai Jiangshan <> | Subject | Re: [PATCH v3 tip/core/rcu 1/9] rcu: Add call_rcu_tasks() |
| |
On 08/04/2014 10:56 PM, Peter Zijlstra wrote: > On Mon, Aug 04, 2014 at 02:25:15PM +0200, Peter Zijlstra wrote: >> On Mon, Aug 04, 2014 at 04:50:44AM -0700, Paul E. McKenney wrote: >>> OK, I will bite... >>> >>> What kinds of tasks are on a runqueue, but neither ->on_cpu nor >>> PREEMPT_ACTIVE? >> >> Userspace tasks, they don't necessarily get PREEMPT_ACTIVE when >> preempted. Now obviously you're not _that_ interested in userspace tasks >> for this, so that might be ok. >> >> But the main point was, you cannot use ->on_cpu or PREEMPT_ACTIVE >> without holding rq->lock. > > Hmm, maybe you can, we have the context switch in between setting > ->on_cpu and clearing PREEMPT_ACTIVE and vice-versa. > > The context switch (obviously) provides a full barrier, so we might be > able to -- with careful consideration -- read these two separate values > and construct something usable from them. > > Something like: > > task_preempt_count(tsk) & PREEMPT_ACTIVE the @tsk is running on_cpu, the above result is false. > smp_rmb(); > tsk->on_cpu now the @tsk is preempted, the above result also is false.
so it is useless if we fetch the preempt_count and on_cpu in two separated instructions. Maybe it would work if we also take tsk->nivcsw in consideration. (I just noticed that tsk->n[i]vcsw are the version numbers for the tsk->on_cpu)
bool task_on_cpu_or_preempted(tsk) { unsigned long saved_nivcsw;
saved_nivcsw = task->nivcsw; if (tsk->on_cpu) return true;
smp_rmb();
if (task_preempt_count(tsk) & PREEMPT_ACTIVE) return true;
smp_rmb();
if (tsk->on_cpu || task->nivcsw != saved_nivcsw) return true;
return false; }
> > And because we set PREEMPT_ACTIVE before clearing on_cpu, this should > race the right way (err towards the inclusive side). > > Obviously that wants a big fat comment...
| |