Messages in this thread | | | Date | Mon, 5 Sep 2016 06:57:37 -0700 | From | "Paul E. McKenney" <> | Subject | Re: Question on smp_mb__before_spinlock |
| |
On Mon, Sep 05, 2016 at 01:34:35PM +0200, Peter Zijlstra wrote: > On Mon, Sep 05, 2016 at 03:37:14AM -0700, Paul E. McKenney wrote: > > On Mon, Sep 05, 2016 at 11:37:53AM +0200, Peter Zijlstra wrote: > > > Hi all, > > > > > > So recently I've had two separate issues that touched upon > > > smp_mb__before_spinlock(). > > > > > > > > > Since its inception, our understanding of ACQUIRE, esp. as applied to > > > spinlocks, has changed somewhat. Also, I wonder if, with a simple > > > change, we cannot make it provide more. > > > > > > The problem with the comment is that the STORE done by spin_lock isn't > > > itself ordered by the ACQUIRE, and therefore a later LOAD can pass over > > > it and cross with any prior STORE, rendering the default WMB > > > insufficient (pointed out by Alan). > > > > > > Now, this is only really a problem on PowerPC and ARM64, the former of > > > which already defined smp_mb__before_spinlock() as a smp_mb(), the > > > latter does not, Will? > > > > > > The second issue I wondered about is spinlock transitivity. All except > > > powerpc have RCsc locks, and since Power already does a full mb, would > > > it not make sense to put it _after_ the spin_lock(), which would provide > > > the same guarantee, but also upgrades the section to RCsc. > > > > > > That would make all schedule() calls fully transitive against one > > > another. > > > > > > > > > That is, would something like the below make sense? > > > > Looks to me like you have reinvented smp_mb__after_unlock_lock()... > > Will said the same, but that one doesn't in fact do the first bit, as > ARM64 also needs a full barrier for that, while it doesn't need that to > upgrade to RCsc.
Fair enough!
Thanx, Paul
| |