Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1580009 > unrolled thread

Re: Question about DEC Alpha memory ordering

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Question about DEC Alpha memory ordering "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-02-13 20:10 +0100
    Re: Question about DEC Alpha memory ordering Michael Cree <mcree@orcon.net.nz> - 2017-02-13 20:30 +0100
      Re: Question about DEC Alpha memory ordering "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-02-13 21:40 +0100
    Re: Question about DEC Alpha memory ordering Tobias Klausmann <klausman@schwarzvogel.de> - 2017-02-13 20:40 +0100
      Re: Question about DEC Alpha memory ordering "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-02-13 21:30 +0100
        Re: Question about DEC Alpha memory ordering Alan Stern <stern@rowland.harvard.edu> - 2017-02-13 22:10 +0100
          Re: Question about DEC Alpha memory ordering "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-02-13 22:30 +0100
            Re: Question about DEC Alpha memory ordering Andrea Parri <parri.andrea@gmail.com> - 2017-02-14 12:40 +0100
              Re: Question about DEC Alpha memory ordering Michael Cree <mcree@orcon.net.nz> - 2017-02-14 20:30 +0100
                Re: Question about DEC Alpha memory ordering Andrea Parri <parri.andrea@gmail.com> - 2017-02-14 21:20 +0100

#1580009 — Re: Question about DEC Alpha memory ordering

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!

							Thanx, Paul

[ . . . ]

[toc] | [next] | [standalone]

#1580036

Hi Paul,

On Mon, Feb 13, 2017 at 11:09:31AM -0800, 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'm that guy with an SMP Alpha system who met you at Linux Conference
Australia after your talk on memory barriers.  I meant to get back to
you but tracking down a kernel bug and now a binutils/glibc bug has
got the better of my time.

Feel free to email me personally to arrange remote access to an SMP
Alpha system, preferrably with a GPG signed message.

Cheers
Michael.

[toc] | [prev] | [next] | [standalone]

#1580065

On Tue, Feb 14, 2017 at 08:23:34AM +1300, Michael Cree wrote:
> Hi Paul,
> 
> On Mon, Feb 13, 2017 at 11:09:31AM -0800, 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'm that guy with an SMP Alpha system who met you at Linux Conference
> Australia after your talk on memory barriers.  I meant to get back to
> you but tracking down a kernel bug and now a binutils/glibc bug has
> got the better of my time.
> 
> Feel free to email me personally to arrange remote access to an SMP
> Alpha system, preferrably with a GPG signed message.

Would you be willing to extend this offer to Andrea Parri (CCed)?
He is the one who has run such tests in the past.

							Thanx, Paul

[toc] | [prev] | [next] | [standalone]

#1580041

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.

Regards,
Tobias

-- 
Sent from aboard the Culture ship
	Stargazer Sober Counsel (Zetetic Elench)

[toc] | [prev] | [next] | [standalone]

#1580061

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);
	WRITE_ONCE(*u0, r1);
}

exists
(0:r1=1 /\ 1:r1=1)

[toc] | [prev] | [next] | [standalone]

#1580077

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)

Alan

[toc] | [prev] | [next] | [standalone]

#1580083

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)

[toc] | [prev] | [next] | [standalone]

#1580490

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 ...

[toc] | [prev] | [next] | [standalone]

#1580777

On Tue, Feb 14, 2017 at 12:35:58PM +0100, Andrea Parri wrote:
> On Mon, Feb 13, 2017 at 01:24:36PM -0800, Paul E. McKenney wrote:
> > ------------------------------------------------------------------------
> > 
> > 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.

This is the test run on a 3-cpu ES45 with the settings in the Makefile:

Test auto/LB-LRW+OB-Ov Allowed
Histogram (2 states)
5913093	:> 0:r1=0; 1:r1=0; 
4086907	:> 0:r1=0; 1:r1=1; 
No
Witnesses
Positive: 0 Negative: 10000000
Condition exists (0:r1=1 /\ 1:r1=1) is NOT validated
Observation auto/LB-LRW+OB-Ov Never 0 10000000
Time auto/LB-LRW+OB-Ov 9.570
Hash=200258693ffc841829310726a4a0b7e3

How do we interpret these results?

Cheers
Michael.

[toc] | [prev] | [next] | [standalone]

#1580837

On Wed, Feb 15, 2017 at 08:26:46AM +1300, Michael Cree wrote:
> On Tue, Feb 14, 2017 at 12:35:58PM +0100, Andrea Parri wrote:
> > On Mon, Feb 13, 2017 at 01:24:36PM -0800, Paul E. McKenney wrote:
> > > ------------------------------------------------------------------------
> > > 
> > > 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.
> 
> This is the test run on a 3-cpu ES45 with the settings in the Makefile:
> 
> Test auto/LB-LRW+OB-Ov Allowed
> Histogram (2 states)
> 5913093	:> 0:r1=0; 1:r1=0; 
> 4086907	:> 0:r1=0; 1:r1=1; 
> No
> Witnesses
> Positive: 0 Negative: 10000000
> Condition exists (0:r1=1 /\ 1:r1=1) is NOT validated
> Observation auto/LB-LRW+OB-Ov Never 0 10000000
> Time auto/LB-LRW+OB-Ov 9.570
> Hash=200258693ffc841829310726a4a0b7e3
> 
> How do we interpret these results?

Hi Michael. The log shows (together w/ other info.) an histogram

  [Total count]   :> [Final state]

where "Total count" is the number of times an execution of the test program
led to the associated "Final state", here represented by the final values
of the registers 0:r1, 1:r1.

The log also shows statistics relative to the final state specified by the
program's "exists" clause, here (0:r1=1 /\ 1:r1=1): this state was never
observed (Positive: 0) over a total of 10000000 iterations/executions.

Thank you for running the test and for sharing these results.

  Andrea

> 
> Cheers
> Michael.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web