On Thu, Sep 17, 2015 at 07:01:11PM +0200, Oleg Nesterov wrote: > On 09/17, Peter Zijlstra wrote: > > > > Included in it are some of the details on this subject, because a wakeup > > has two prior states that are of importance, the tasks own prior state > > and the wakeup state, both should be considered in the 'program order' > > flow. > > Great. Just one question, > > > + * BLOCKING -- aka. SLEEP + WAKEUP > > + * > > + * For blocking things are a little more interesting, because when we dequeue > > + * the task, we don't need to acquire the old rq lock in order to migrate it. > > + * > > + * Say CPU0 does a wait_event() and CPU1 does the wake() and migrates the task > > + * to CPU2 (the most complex example): > > + * > > + * CPU0 (schedule) CPU1 (try_to_wake_up) CPU2 (sched_ttwu_pending) > > + * > > + * X->state = UNINTERRUPTIBLE > > + * MB > > + * if (cond) > > + * break > > + * cond = true > > + * > > + * WMB WMB (aka smp_mb__before_spinlock) > > Yes, both CPU's do WMB-aka-smp_mb__before_spinlock... > > But afaics in this particular case we do not really need them? > So perhaps we should not even mention them? > > Because (if I am right) this can confuse the reader who will try > to understand how/where do we rely on these barriers. Good point. Initially I put all barriers in, but now that we've figured out which are important (the text is correct, right? please double check) we can remove the rest. -- 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
