On Tue, 2016-08-30 at 20:34 +0200, Peter Zijlstra wrote: > > I'm not actually sure it does. There is the comment from 8643cda549ca4 > which explain the program order guarantees. > > But I'm not sure who or what would simply a full smp_mb() when you call > schedule() -- I mean, its true on x86, but that's 'trivial'.
It's always been a requirement that if you actually context switch a full mb() is implied (though that isn't the case if you don't actually switch, ie, you are back to RUNNING before you even hit schedule). On powerpc we have a sync deep in _switch to achieve that. This is necessary so that a process who wakes up on a different CPU sees all of its own load/stores. > > I mean, I thought that the LOAD/STORE's done by some task can't > > be re-ordered with LOAD/STORE's done by another task which was > > running on the same CPU. Wrong? > > If so, I'm not sure how :/ > > So smp_mb__before_spinlock() stops stores from @prev, and the ACQUIRE > from spin_lock(&rq->lock) stops both loads/stores from @next, but afaict > nothing stops the loads from @prev seeing stores from @next. > > Also not sure this matters though, if they're threads in the same > process its a data race already and nobody cares. If they're not threads > in the same process, they're separated by address space and can't 'see' > each other anyway. The architecture switch_to() has to do the right thing. Cheers, Ben.
