Hi Will, On Tue, Sep 15, 2015 at 05:13:30PM +0100, Will Deacon wrote: > As much as we'd like to live in a world where RELEASE -> ACQUIRE is > always cheaply ordered and can be used to construct UNLOCK -> LOCK > definitions with similar guarantees, the grim reality is that this isn't > even possible on x86 (thanks to Paul for bringing us crashing down to > Earth). > > This patch handles the issue by introducing a new barrier macro, > smp_mb__release_acquire, that can be placed between a RELEASE and a > subsequent ACQUIRE operation in order to upgrade them to a full memory > barrier. At the moment, it doesn't have any users, so its existence > serves mainly as a documentation aid. > > Documentation/memory-barriers.txt is updated to describe more clearly > the ACQUIRE and RELEASE ordering in this area and to show an example of > the new barrier in action. > > Cc: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> > Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx> > Signed-off-by: Will Deacon <will.deacon@xxxxxxx> > --- > > Following our discussion at [1], I thought I'd try to write something > down... > > [1] http://lkml.kernel.org/r/20150828104854.GB16853@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > Documentation/memory-barriers.txt | 23 ++++++++++++++++++++++- > arch/powerpc/include/asm/barrier.h | 1 + > arch/x86/include/asm/barrier.h | 2 ++ > include/asm-generic/barrier.h | 4 ++++ > 4 files changed, 29 insertions(+), 1 deletion(-) > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > index 2ba8461b0631..46a85abb77c6 100644 > --- a/Documentation/memory-barriers.txt > +++ b/Documentation/memory-barriers.txt > @@ -459,11 +459,18 @@ And a couple of implicit varieties: > RELEASE on that same variable are guaranteed to be visible. In other > words, within a given variable's critical section, all accesses of all > previous critical sections for that variable are guaranteed to have > - completed. > + completed. If the RELEASE and ACQUIRE operations act on independent > + variables, an smp_mb__release_acquire() barrier can be placed between > + them to upgrade the sequence to a full barrier. > > This means that ACQUIRE acts as a minimal "acquire" operation and > RELEASE acts as a minimal "release" operation. > > +A subset of the atomic operations described in atomic_ops.txt have ACQUIRE > +and RELEASE variants in addition to fully-ordered and relaxed definitions. > +For compound atomics performing both a load and a store, ACQUIRE semantics > +apply only to the load and RELEASE semantics only to the store portion of > +the operation. > > Memory barriers are only required where there's a possibility of interaction > between two CPUs or between a CPU and a device. If it can be guaranteed that > @@ -1895,6 +1902,20 @@ the RELEASE would simply complete, thereby avoiding the deadlock. > a sleep-unlock race, but the locking primitive needs to resolve > such races properly in any case. > > +If necessary, ordering can be enforced by use of an > +smp_mb__release_acquire() barrier: > + > + *A = a; > + RELEASE M > + smp_mb__release_acquire(); Should this barrier be placed after the ACQUIRE? Because we do actually want(?) and allow RELEASE and ACQUIRE operations to reorder in this case, like your following example, right? Regards, Boqun > + ACQUIRE N > + *B = b; > + > +in which case, the only permitted sequences are: > + > + STORE *A, RELEASE M, ACQUIRE N, STORE *B > + STORE *A, ACQUIRE N, RELEASE M, STORE *B > +
Attachment:
signature.asc
Description: PGP signature
