From: Will Deacon <will.deacon@arm.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Michael Ellerman <mpe@ellerman.id.au>,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
Boqun Feng <boqun.feng@gmail.com>,
Anton Blanchard <anton@samba.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation
Date: Fri, 9 Oct 2015 10:51:29 +0100 [thread overview]
Message-ID: <20151009095129.GF26278@arm.com> (raw)
In-Reply-To: <20151008221716.GF3910@linux.vnet.ibm.com>
Hi Paul,
On Thu, Oct 08, 2015 at 03:17:16PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 08, 2015 at 01:59:38PM +0100, Will Deacon wrote:
> > I thought Paul was talking about something like this case:
> >
> > CPU A CPU B CPU C
> > foo = 1
> > UNLOCK x
> > LOCK x
> > (RELEASE) bar = 1
> > ACQUIRE bar = 1
> > READ_ONCE foo = 0
>
> More like this:
>
> CPU A CPU B CPU C
> WRITE_ONCE(foo, 1);
> UNLOCK x
> LOCK x
> r1 = READ_ONCE(bar);
> WRITE_ONCE(bar, 1);
> smp_mb();
> r2 = READ_ONCE(foo);
>
> This can result in r1==0 && r2==0.
Thank you, that is extremely enlightening :)
> > I think we need a PPC litmus test illustrating the inter-thread, same
> > lock failure case when smp_mb__after_unlock_lock is not present so that
> > we can reason about this properly. Paul?
>
> Please see above. ;-)
>
> The corresponding litmus tests are below.
How do people feel about including these in memory-barriers.txt? I find
them considerably easier to read than our current kernel code + list of
possible orderings + wall of text, but there's a good chance that my
brain has been corrupted from staring at this stuff for too long.
The only snag is the ppc assembly code, but it's not *too* horrific ;)
> PPC lock-2thread-WR-barrier.litmus
> ""
> (*
> * Does 3.0 Linux-kernel Power lock-unlock provide local
> * barrier that orders prior stores against subsequent loads,
> * if the unlock and lock happen on different threads?
> * This version uses lwsync instead of isync.
> *)
> (* 23-July-2013: ppcmem says "Sometimes" *)
> {
> l=1;
> 0:r1=1; 0:r4=x; 0:r10=0; 0:r12=l;
> 1:r1=1; 1:r3=42; 1:r4=x; 1:r5=y; 1:r10=0; 1:r11=0; 1:r12=l;
> 2:r1=1; 2:r4=x; 2:r5=y;
> }
> P0 | P1 | P2;
> stw r1,0(r4) | lwarx r11,r10,r12 | stw r1,0(r5) ;
> lwsync | cmpwi r11,0 | lwsync ;
> stw r10,0(r12) | bne Fail1 | lwz r7,0(r4) ;
> | stwcx. r1,r10,r12 | ;
> | bne Fail1 | ;
> | isync | ;
> | lwz r3,0(r5) | ;
> | Fail1: | ;
>
>
> exists
> (1:r3=0 /\ 2:r7=0)
We could also include a link to the ppcmem/herd web frontends and your
lwn.net article. (ppcmem is already linked, but it's not obvious that
you can run litmus tests in your browser).
Will
next prev parent reply other threads:[~2015-10-09 9:51 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1444215568-24732-1-git-send-email-will.deacon@arm.com>
[not found] ` <20151007111915.GF17308@twins.programming.kicks-ass.net>
[not found] ` <20151007132317.GK16065@arm.com>
[not found] ` <20151007152501.GI3910@linux.vnet.ibm.com>
2015-10-08 3:50 ` [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation Michael Ellerman
2015-10-08 11:16 ` Peter Zijlstra
2015-10-08 12:59 ` Will Deacon
2015-10-08 22:17 ` Paul E. McKenney
2015-10-09 9:51 ` Will Deacon [this message]
2015-10-09 11:25 ` Peter Zijlstra
2015-10-09 17:44 ` Paul E. McKenney
2015-10-09 17:43 ` Paul E. McKenney
2015-10-09 18:33 ` Will Deacon
2015-10-12 23:30 ` Paul E. McKenney
2015-10-20 14:20 ` Boqun Feng
2015-10-08 21:44 ` Paul E. McKenney
2015-10-09 7:29 ` Peter Zijlstra
2015-10-09 8:31 ` Peter Zijlstra
2015-10-09 9:40 ` Will Deacon
2015-10-09 11:02 ` Peter Zijlstra
2015-10-09 12:41 ` Will Deacon
2015-10-09 11:12 ` Peter Zijlstra
2015-10-09 12:51 ` Will Deacon
2015-10-09 13:06 ` Peter Zijlstra
2015-10-09 11:13 ` Peter Zijlstra
2015-10-09 17:21 ` Paul E. McKenney
2015-10-19 1:17 ` Boqun Feng
2015-10-19 10:23 ` Peter Zijlstra
2015-10-20 7:35 ` Boqun Feng
2015-10-20 23:34 ` Paul E. McKenney
2015-10-21 8:24 ` Peter Zijlstra
2015-10-21 19:29 ` Paul E. McKenney
2015-10-21 19:36 ` Peter Zijlstra
2015-10-21 19:56 ` Paul E. McKenney
2015-10-21 16:04 ` David Laight
2015-10-21 19:34 ` Paul E. McKenney
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=20151009095129.GF26278@arm.com \
--to=will.deacon@arm.com \
--cc=anton@samba.org \
--cc=benh@kernel.crashing.org \
--cc=boqun.feng@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulmck@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).