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. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
