Messages in this thread | | | From | Catalin Marinas <> | Date | Fri, 16 Oct 2015 17:55:35 +0100 | Subject | Re: Q: schedule() and implied barriers on arm64 |
| |
I'll try to reply in Will's absence, though I gave up trying to understand these threads long time ago ;).
On 16 October 2015 at 17:16, Peter Zijlstra <peterz@infradead.org> wrote: > On Fri, Oct 16, 2015 at 09:04:22AM -0700, Paul E. McKenney 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. >> >> But I thought that it used a dmb in the spinlock code somewhere or >> another... > > arm does, arm64 not so much.
arm64 indeed does not have a dmb after spin_lock, it only has a load-acquire. So with the default smp_mb__before_spinlock() + spin_lock we have:
smp_wmb() loop load-acquire store
So (I think) this guarantees that any writes before wmb+lock would be visible before any reads _and_ writes after wmb+lock. However, the ordering with reads before wmb+lock is not guaranteed.
-- Catalin
| |