From: Andrea Parri <parri.andrea@gmail.com>
To: klausman@schwarzvogel.de,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
stern@rowland.harvard.edu
Cc: bob smith <sfmc68@verizon.net>,
rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com,
j.alglave@ucl.ac.uk, luc.maranget@inria.fr, will.deacon@arm.com,
linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Question about DEC Alpha memory ordering
Date: Tue, 14 Feb 2017 12:35:58 +0100 [thread overview]
Message-ID: <20170214113558.GA15525@andrea> (raw)
In-Reply-To: <20170213212436.GQ30506@linux.vnet.ibm.com>
On Mon, Feb 13, 2017 at 01:24:36PM -0800, Paul E. McKenney wrote:
> On Mon, Feb 13, 2017 at 04:06:21PM -0500, Alan Stern wrote:
> > On Mon, 13 Feb 2017, Paul E. McKenney wrote:
> >
> > > On Mon, Feb 13, 2017 at 08:14:23PM +0100, Tobias Klausmann wrote:
> > > > Hi!
> > > >
> > > > On Mon, 13 Feb 2017, Paul E. McKenney wrote:
> > > > > On Mon, Feb 13, 2017 at 01:53:27PM -0500, bob smith wrote:
> > > > > > On 2/13/17 1:39 PM, Paul E. McKenney wrote:
> > > > > > > can real DEC Alpha hardware end up with both instances of "r1"
> > > > > > > having the value 1?
> > > > > >
> > > > > > I thought this question reminded me of something, so I found this:
> > > > > > > https://www.kernel.org/doc/Documentation/memory-barriers.txt
> > > > > >
> > > > > > and I pasted in the content - David Howells is one of the authors and
> > > > > > maybe that is why the question sort of reminded me.
> > > > > >
> > > > > > Maybe someone has an update but this is what was said then.
> > > > >
> > > > > Well, thank you for pointing me to this, but my question was intended to
> > > > > check whether or not the words I helped to write in memory-barriers.txt
> > > > > are in fact accurate. So if you have an SMP DEC Alpha system that you
> > > > > could provide remote access to, that would be very helpful!
> > > >
> > > > I have a 4-cpu ES40. Send me a test program and I'll gladly run
> > > > it for you.
> > >
> > > Andrea, could you please convert the litmus test below and send it to
> > > Tobias?
> > >
> > > Thanx, Paul
> > >
> > > ------------------------------------------------------------------------
> > >
> > > C auto/C-LB-LRW+OB-Dv
> > > (*
> > > * Result: Never
> > > *
> > > *)
> > > {
> > > }
> > >
> > > P0(int *u0, int *x1)
> > > {
> > > r1 = READ_ONCE(*u0);
> > > smp_mb();
> > > WRITE_ONCE(*x1, 1);
> > > }
> > >
> > >
> > > P1(int *u0, int *x1)
> > > {
> > > r1 = rcu_dereference(*x1);
> >
> > No, please, not this. It should be:
> >
> > r1 = READ_ONCE(*x1);
> >
> > That is, the auto/C-LB-LRW+OB-Ov.litmus test.
> >
> > > WRITE_ONCE(*u0, r1);
> > > }
> > >
> > > exists
> > > (0:r1=1 /\ 1:r1=1)
>
> Sorry, here is the correct one in full.
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> C auto/C-LB-LRW+OB-Ov
> (*
> * Result: Maybe
> * P0-P1 rf OB-Ov: Never->Maybe: Note lack of C11 guarantee, control dependency
> * P1 Ov,LRW: Note lack of C11 guarantee, control dependency
> *)
> {
> }
>
> P0(int *u0, int *x1)
> {
> r1 = READ_ONCE(*u0);
> smp_mb();
> WRITE_ONCE(*x1, 1);
> }
>
>
> P1(int *u0, int *x1)
> {
> r1 = READ_ONCE(*x1);
> WRITE_ONCE(*u0, r1);
> }
>
> exists
> (0:r1=1 /\ 1:r1=1)
>
The (automatically generated) module for this test is at
http://retis.sssup.it/~a.parri/lkmm/C-LB-LRW+OB-Ov.tgz ;
the test is run by cat-ing /sys/kernel/litmus/p_count: this will execute
the thread bodies for "runs * size" iterations; results can be sentisive
to the "stride" and "affinity increment" parameters (c.f., the Makefile);
statistics for each experiments are printed on stdout.
Please let me know should you find any problem with this. Thank you,
Andrea
Disclaimer: I'm not "excited", to use an euphemism, to post such an ugly
C code to LKML ...; _most importantly_, I've certainly never tested this
on any Alpha machine ...
next prev parent reply other threads:[~2017-02-14 11:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 18:39 Question about DEC Alpha memory ordering Paul E. McKenney
2017-02-13 18:53 ` bob smith
2017-02-13 19:08 ` Will Deacon
2017-02-13 19:09 ` Paul E. McKenney
2017-02-13 19:14 ` Tobias Klausmann
2017-02-13 20:28 ` Paul E. McKenney
2017-02-13 21:06 ` Alan Stern
2017-02-13 21:06 ` Alan Stern
2017-02-13 21:24 ` Paul E. McKenney
2017-02-14 11:35 ` Andrea Parri [this message]
2017-02-14 19:26 ` Michael Cree
2017-02-14 20:12 ` Andrea Parri
2017-02-13 19:23 ` Michael Cree
2017-02-13 20:32 ` 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=20170214113558.GA15525@andrea \
--to=parri.andrea@gmail.com \
--cc=ink@jurassic.park.msu.ru \
--cc=j.alglave@ucl.ac.uk \
--cc=klausman@schwarzvogel.de \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=mattst88@gmail.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rth@twiddle.net \
--cc=sfmc68@verizon.net \
--cc=stern@rowland.harvard.edu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.