On 16 October 2015 at 17:04, Paul E. McKenney <[email protected]> wrote: > On Fri, Oct 16, 2015 at 05:18:30PM +0200, Peter Zijlstra wrote: >> If so, however, I suspect AARGH64 is borken and would need (just like >> PPC): >> >> #define smp_mb__before_spinlock() smp_mb() >> >> The problem is that schedule() (when a NO-OP) does: >> >> smp_mb__before_spinlock(); >> LOCK rq->lock >> >> clear_bit() >> >> UNLOCK rq->lock >> >> And nothing there implies a full barrier on AARGH64, since >> smp_mb__before_spinlock() defaults to WMB, LOCK is an "ldaxr" or >> load-acquire, UNLOCK is "stlrh" or store-release and clear_bit() isn't >> anything. >> >> Pretty much every other arch has LOCK implying a full barrier, either >> because its strongly ordered or because it needs one for the ACQUIRE >> semantics. > > Well, arm64 might well need smp_mb__after_unlock_lock() to be non-empty. > But I thought that it used a dmb in the spinlock code somewhere or > another...
unlock+lock on arm64 is a full barrier, so, IIUC the semantics of smp_mb__after_unlock_lock(), I don't think we need this to be non-empty. Maybe redefining smp_mb__before_spinlock() to be smp_mb() (rather than wmb) on arm64 if we need smp_mb__before_spinlock+lock to act as a barrier for both reads and writes (see my other reply to Peter). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
