Messages in this thread | | | Date | Mon, 21 Sep 2015 19:46:11 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH] Documentation: Remove misleading examples of the barriers in wake_*() |
| |
On 09/18, Peter Zijlstra wrote: > > the text is correct, right?
Yes, it looks good to me and helpful.
But damn. I forgot why exactly try_to_wake_up() needs rmb() after ->on_cpu check... It looks reasonable in any case, but I do not see any strong reason immediately.
Say,
p->sched_contributes_to_load = !!task_contributes_to_load(p); p->state = TASK_WAKING;
we can actually do this before "while (p->on_cpu)", afaics. However we must not do this before the previous p->on_rq check.
So perhaps this rmb() helps to ensure task_contributes_to_load() can't happen before p->on_rq check...
As for "p->state = TASK_WAKING" we have the control dependency in both cases. But the modern fashion suggests to use _CTRL(). Although cpu_relax() should imply barrier(), but afaik this is not documented.
In short, I got lost ;) Now I don't even understand why we do not need another rmb() between p->on_rq and p->on_cpu. Suppose a thread T does
set_current_state(...); schedule();
it can be preempted in between, after that we have "on_rq && !on_cpu". Then it gets CPU again and calls schedule() which clears on_rq.
What guarantees that if ttwu() sees on_rq == 0 cleared by schedule() then it can _not_ still see the old value of on_cpu == 0?
Oleg.
| |