From: Boqun Feng <boqun.feng@gmail.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Ingo Molnar <mingo@kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will.deacon@arm.com>,
Waiman Long <waiman.long@hp.com>,
Davidlohr Bueso <dave@stgolabs.net>,
stable@vger.kernel.org
Subject: Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier
Date: Thu, 15 Oct 2015 11:11:01 +0800 [thread overview]
Message-ID: <20151015031101.GD14305@fixme-laptop.cn.ibm.com> (raw)
In-Reply-To: <20151015005321.GB29432@fixme-laptop.cn.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3140 bytes --]
Hi Paul,
On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote:
> On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
[snip]
> > To that end, the herd tool can make a diagram of what it thought
> > happened, and I have attached it. I used this diagram to try and force
> > this scenario at https://www.cl.cam.ac.uk/~pes20/ppcmem/index.html#PPC,
> > and succeeded. Here is the sequence of events:
> >
> > o Commit P0's write. The model offers to propagate this write
> > to the coherence point and to P1, but don't do so yet.
> >
> > o Commit P1's write. Similar offers, but don't take them up yet.
> >
> > o Commit P0's lwsync.
> >
> > o Execute P0's lwarx, which reads a=0. Then commit it.
> >
> > o Commit P0's stwcx. as successful. This stores a=1.
> >
> > o Commit P0's branch (not taken).
> >
>
> So at this point, P0's write to 'a' has propagated to P1, right? But
> P0's write to 'x' hasn't, even there is a lwsync between them, right?
> Doesn't the lwsync prevent this from happening?
>
> If at this point P0's write to 'a' hasn't propagated then when?
>
Hmm.. I played around ppcmem, and figured out what happens to
propagation of P0's write to 'a':
At this point, or some point after store 'a' to 1 and before sync on
P1 finish, writes to 'a' reachs a coherence point which 'a' is 2, so
P0's write to 'a' "fails" and will not propagate.
I probably misunderstood the word "propagate", which actually means an
already coherent write gets seen by another CPU, right?
So my question should be:
As lwsync can order P0's write to 'a' happens after P0's write to 'x',
why P0's write to 'x' isn't seen by P1 after P1's write to 'a' overrides
P0's?
But ppcmem gave me the answer ;-) lwsync won't wait under P0's write to
'x' gets propagated, and if P0's write to 'a' "wins" in write coherence,
lwsync will guarantee propagation of 'x' happens before that of 'a', but
if P0's write to 'a' "fails", there will be no propagation of 'a' from
P0. So that lwsync can't do anything here.
Regards,
Boqun
>
> > o Commit P0's final register-to-register move.
> >
> > o Commit P1's sync instruction.
> >
> > o There is now nothing that can happen in either processor.
> > P0 is done, and P1 is waiting for its sync. Therefore,
> > propagate P1's a=2 write to the coherence point and to
> > the other thread.
> >
> > o There is still nothing that can happen in either processor.
> > So pick the barrier propagate, then the acknowledge sync.
> >
> > o P1 can now execute its read from x. Because P0's write to
> > x is still waiting to propagate to P1, this still reads
> > x=0. Execute and commit, and we now have both r3 registers
> > equal to zero and the final value a=2.
> >
> > o Clean up by propagating the write to x everywhere, and
> > propagating the lwsync.
> >
> > And the "exists" clause really does trigger: 0:r3=0; 1:r3=0; [a]=2;
> >
> > I am still not 100% confident of my litmus test. It is quite possible
> > that I lost something in translation, but that is looking less likely.
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-10-15 3:11 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-14 15:55 [PATCH tip/locking/core v4 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics Boqun Feng
2015-10-14 15:55 ` [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier Boqun Feng
2015-10-14 20:19 ` Paul E. McKenney
2015-10-14 21:04 ` Peter Zijlstra
2015-10-14 21:44 ` Paul E. McKenney
2015-10-15 0:53 ` Boqun Feng
2015-10-15 1:22 ` Boqun Feng
2015-10-15 3:07 ` Paul E. McKenney
2015-10-15 3:07 ` Paul E. McKenney
2015-10-15 4:48 ` Boqun Feng
2015-10-15 16:30 ` Paul E. McKenney
2015-10-19 0:19 ` Boqun Feng
2015-10-15 3:11 ` Boqun Feng [this message]
2015-10-15 3:33 ` Paul E. McKenney
2015-10-15 10:35 ` Will Deacon
2015-10-15 14:40 ` Boqun Feng
2015-10-15 14:50 ` Will Deacon
2015-10-15 16:29 ` Paul E. McKenney
2015-10-15 15:42 ` Paul E. McKenney
2015-10-15 14:49 ` Boqun Feng
2015-10-15 16:16 ` Paul E. McKenney
2015-10-20 7:15 ` Boqun Feng
2015-10-20 9:21 ` Peter Zijlstra
2015-10-20 21:28 ` Paul E. McKenney
2015-10-21 8:18 ` Peter Zijlstra
2015-10-21 19:36 ` Paul E. McKenney
2015-10-26 2:06 ` Boqun Feng
2015-10-26 2:20 ` Michael Ellerman
2015-10-26 8:55 ` Boqun Feng
2015-10-26 3:20 ` Paul Mackerras
2015-10-26 8:58 ` Boqun Feng
2015-10-21 8:45 ` Boqun Feng
2015-10-21 19:35 ` Paul E. McKenney
2015-10-21 19:48 ` Peter Zijlstra
2015-10-22 12:07 ` Boqun Feng
2015-10-24 10:26 ` Peter Zijlstra
2015-10-24 11:53 ` Boqun Feng
2015-10-25 13:14 ` Boqun Feng
2015-10-14 15:55 ` [PATCH tip/locking/core v4 2/6] atomics: Add test for atomic operations with _relaxed variants Boqun Feng
2015-10-14 15:55 ` [PATCH tip/locking/core v4 3/6] atomics: Allow architectures to define their own __atomic_op_* helpers Boqun Feng
2015-10-14 15:55 ` [PATCH tip/locking/core v4 4/6] powerpc: atomic: Implement atomic{,64}_*_return_* variants Boqun Feng
2015-10-14 15:56 ` [PATCH tip/locking/core v4 5/6] powerpc: atomic: Implement xchg_* and atomic{,64}_xchg_* variants Boqun Feng
2015-10-14 15:56 ` [PATCH tip/locking/core v4 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants 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=20151015031101.GD14305@fixme-laptop.cn.ibm.com \
--to=boqun.feng@gmail.com \
--cc=benh@kernel.crashing.org \
--cc=dave@stgolabs.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=paulmck@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=waiman.long@hp.com \
--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
all inboxes | Powered by JetHome®