Messages in this thread | | | From | Catalin Marinas <> | Date | Fri, 16 Oct 2015 18:11:05 +0100 | Subject | Re: Q: schedule() and implied barriers on arm64 |
| |
On 16 October 2015 at 17:04, Paul E. McKenney <paulmck@linux.vnet.ibm.com> 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
| |