From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Boqun Feng <boqun.feng@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation
Date: Tue, 22 Sep 2015 08:22:41 -0700 [thread overview]
Message-ID: <20150922152241.GN4029@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150921222301.GF7356@arm.com>
On Mon, Sep 21, 2015 at 11:23:01PM +0100, Will Deacon wrote:
> On Mon, Sep 21, 2015 at 03:10:38PM +0100, Boqun Feng wrote:
> > On Mon, Sep 21, 2015 at 09:45:15PM +0800, Boqun Feng wrote:
> > > On Thu, Sep 17, 2015 at 07:00:01PM +0100, Will Deacon wrote:
> > > > On Thu, Sep 17, 2015 at 03:50:12AM +0100, Boqun Feng wrote:
> > > > > If an ACQUIRE loads the value of stored by a RELEASE, then after the
> > > > > ACQUIRE operation, the CPU executing the ACQUIRE operation will perceive
> > > > > all the memory operations that have been perceived by the CPU executing
> > > > > the RELEASE operation before the RELEASE operation.
> > > > >
> > > > > Which means a release+acquire pair to the same variable guarantees
> > > > > transitivity.
> > > >
> > > > Almost, but on arm64 at least, "all the memory operations" above doesn't
> > > > include reads by other CPUs. I'm struggling to figure out whether that's
> > > > actually an issue.
> > > >
> > >
> > > Ah.. that's indeed an issue! for example:
> > >
> > > CPU 0 CPU 1 CPU 2
> > > ===================== ========================== ================
> > > {a = 0, b = 0, c = 0}
> > > r1 = READ_ONCE(a); WRITE_ONCE(b, 1); r3 = smp_load_acquire(&c);
> > > smp_rmb(); smp_store_release(&c, 1); WRITE_ONCE(a, 1);
> > > r2 = READ_ONCE(b)
> > >
> > > where r1 == 1 && r2 == 0 && r3 == 1 is actually not prohibitted, at
> > > least on POWER.
> > >
> >
> > Oops.. I use wrong litmus here.. so this is prohibitted on POWER. Sorry
> > for the misleading. How about the behavior of that on arm and arm64?
>
> That explicit test is forbidden on arm/arm64 because of the smp_rmb(),
> but if you rewrite it as (LDAR is acquire, STLR is release):
>
>
> {
> 0:X1=x; 0:X3=y;
> 1:X1=y; 1:X2=z;
> 2:X1=z; 2:X3=x;
> }
> P0 | P1 | P2 ;
> LDAR W0,[X1] | MOV W0,#1 | LDAR W0,[X1] ;
> LDR W2,[X3] | STR W0,[X1] | MOV W2,#1 ;
> | STLR W0,[X2] | STR W2,[X3] ;
>
> Observed
> 0:X0=1; 0:X2=0; 2:X0=1;
>
>
> then it is permitted on arm64. Note that herd currently claims that this
> is forbidden, but I'm talking to the authors about getting that fixed :)
But a pure store-release/load-acquire chain would be forbidden in
hardware as well as by herd, correct?
Thanx, Paul
next prev parent reply other threads:[~2015-09-22 15:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-15 16:13 Will Deacon
2015-09-15 17:47 ` Paul E. McKenney
2015-09-16 9:14 ` Peter Zijlstra
2015-09-16 10:29 ` Will Deacon
2015-09-16 10:43 ` Peter Zijlstra
2015-09-16 11:07 ` Will Deacon
2015-09-17 2:50 ` Boqun Feng
2015-09-17 7:57 ` Boqun Feng
2015-09-17 18:00 ` Will Deacon
2015-09-21 13:45 ` Boqun Feng
2015-09-21 14:10 ` Boqun Feng
2015-09-21 22:23 ` Will Deacon
2015-09-21 23:42 ` Boqun Feng
2015-09-22 15:22 ` Paul E. McKenney [this message]
2015-09-22 15:58 ` Will Deacon
2015-09-22 16:38 ` Paul E. McKenney
2015-09-16 11:49 ` Boqun Feng
2015-09-16 16:38 ` Will Deacon
2015-09-17 1:56 ` Boqun Feng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150922152241.GN4029@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=boqun.feng@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome