[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160906174209.GB29382@arm.com>
Date: Tue, 6 Sep 2016 18:42:10 +0100
From: Will Deacon <will.deacon@....com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Michael Ellerman <mpe@...erman.id.au>,
linux-kernel@...r.kernel.org, Nicholas Piggin <npiggin@...il.com>,
Ingo Molnar <mingo@...nel.org>,
Alan Stern <stern@...land.harvard.edu>
Subject: Re: Question on smp_mb__before_spinlock
On Tue, Sep 06, 2016 at 01:17:53PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 05, 2016 at 11:10:22AM +0100, Will Deacon wrote:
>
> > > 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.
> >
> > It would also match the way in which the arm64 atomic_*_return ops
> > are implemented, since full barrier semantics are required there.
>
> Hmm, are you sure; the way I read arch/arm64/include/asm/atomic_ll_sc.h
> is that you do ll/sc-rel + mb.
Yes, all I meant was that we put the full barrier at the end, but the
two things are indeed different sequences.
Will
Powered by blists - more mailing lists