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

Groups > linux.kernel > #1250273 > unrolled thread

Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

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: [PATCH v2] barriers: introduce smp_mb__release_acquire and  update documentation Boqun Feng <boqun.feng@gmail.com> - 2015-10-19 03:20 +0200
    Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and  update documentation Peter Zijlstra <peterz@infradead.org> - 2015-10-19 12:30 +0200
      Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and  update documentation Boqun Feng <boqun.feng@gmail.com> - 2015-10-20 09:40 +0200
    Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and  update documentation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-21 01:40 +0200
      Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and  update documentation Peter Zijlstra <peterz@infradead.org> - 2015-10-21 10:30 +0200
        Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and  update documentation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-21 21:30 +0200
          Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and  update documentation Peter Zijlstra <peterz@infradead.org> - 2015-10-21 21:40 +0200
            Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and  update documentation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-21 22:00 +0200
      RE: [PATCH v2] barriers: introduce smp_mb__release_acquire and  update documentation David Laight <David.Laight@ACULAB.COM> - 2015-10-21 18:10 +0200
        Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and  update documentation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-21 21:40 +0200

#1250273 — Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

[Multipart message — attachments visible in raw view] — view raw

On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote:
> On Fri, Oct 09, 2015 at 10:31:38AM +0200, Peter Zijlstra wrote:
[snip]
> > 
> > So lots of little confusions added up to complete fail :-{
> > 
> > Mostly I think it was the UNLOCK x + LOCK x are fully ordered (where I
> > forgot: but not against uninvolved CPUs) and RELEASE/ACQUIRE are
> > transitive (where I forgot: RELEASE/ACQUIRE _chains_ are transitive, but
> > again not against uninvolved CPUs).
> > 
> > Which leads me to think I would like to suggest alternative rules for
> > RELEASE/ACQUIRE (to replace those Will suggested; as I think those are
> > partly responsible for my confusion).
> 
> Yeah, sorry. I originally used the phrase "fully ordered" but changed it
> to "full barrier", which has stronger transitivity (newly understood
> definition) requirements that I didn't intend.
> 
> RELEASE -> ACQUIRE should be used for message passing between two CPUs
> and not have ordering effects on other observers unless they're part of
> the RELEASE -> ACQUIRE chain.
> 
> >  - RELEASE -> ACQUIRE is fully ordered (but not a full barrier) when
> >    they operate on the same variable and the ACQUIRE reads from the
> >    RELEASE. Notable, RELEASE/ACQUIRE are RCpc and lack transitivity.
> 
> Are we explicit about the difference between "fully ordered" and "full
> barrier" somewhere else, because this looks like it will confuse people.
> 

This is confusing me right now. ;-)

Let's use a simple example for only one primitive, as I understand it,
if we say a primitive A is "fully ordered", we actually mean:

1.	The memory operations preceding(in program order) A can't be
	reordered after the memory operations following(in PO) A.

and

2.	The memory operation(s) in A can't be reordered before the
	memory operations preceding(in PO) A and after the memory
	operations following(in PO) A.

If we say A is a "full barrier", we actually means:

1.	The memory operations preceding(in program order) A can't be
	reordered after the memory operations following(in PO) A.

and

2.	The memory ordering guarantee in #1 is visible globally.

Is that correct? Or "full barrier" is more strong than I understand,
i.e. there is a third property of "full barrier":

3.	The memory operation(s) in A can't be reordered before the
	memory operations preceding(in PO) A and after the memory
	operations following(in PO) A.

IOW, is "full barrier" a more strong version of "fully ordered" or not?

Regards,
Boqun

> >  - RELEASE -> ACQUIRE can be upgraded to a full barrier (including
> >    transitivity) using smp_mb__release_acquire(), either before RELEASE
> >    or after ACQUIRE (but consistently [*]).
> 
> Hmm, but we don't actually need this for RELEASE -> ACQUIRE, afaict. This
> is just needed for UNLOCK -> LOCK, and is exactly what RCU is currently
> using (for PPC only).
> 
> Stepping back a second, I believe that there are three cases:
> 
> 
>  RELEASE X -> ACQUIRE Y (same CPU)
>    * Needs a barrier on TSO architectures for full ordering
> 
>  UNLOCK X -> LOCK Y (same CPU)
>    * Needs a barrier on PPC for full ordering
> 
>  RELEASE X -> ACQUIRE X (different CPUs)
>  UNLOCK X -> ACQUIRE X (different CPUs)
>    * Fully ordered everywhere...
>    * ... but needs a barrier on PPC to become a full barrier
> 
> 

[toc] | [next] | [standalone]

#1250548

On Mon, Oct 19, 2015 at 09:17:18AM +0800, Boqun Feng wrote:
> This is confusing me right now. ;-)
> 
> Let's use a simple example for only one primitive, as I understand it,
> if we say a primitive A is "fully ordered", we actually mean:
> 
> 1.	The memory operations preceding(in program order) A can't be
> 	reordered after the memory operations following(in PO) A.
> 
> and
> 
> 2.	The memory operation(s) in A can't be reordered before the
> 	memory operations preceding(in PO) A and after the memory
> 	operations following(in PO) A.
> 
> If we say A is a "full barrier", we actually means:
> 
> 1.	The memory operations preceding(in program order) A can't be
> 	reordered after the memory operations following(in PO) A.
> 
> and
> 
> 2.	The memory ordering guarantee in #1 is visible globally.
> 
> Is that correct? Or "full barrier" is more strong than I understand,
> i.e. there is a third property of "full barrier":
> 
> 3.	The memory operation(s) in A can't be reordered before the
> 	memory operations preceding(in PO) A and after the memory
> 	operations following(in PO) A.
> 
> IOW, is "full barrier" a more strong version of "fully ordered" or not?

Yes, that was how I used it.

Now of course; the big question is do we want to promote this usage or
come up with a different set of words describing this stuff.

I think separating the ordering from the transitivity is useful, for we
can then talk about and specify them independently.

That is, we can say:

	LOAD-ACQUIRE: orders LOAD->{LOAD,STORE}
	              weak transitivity (RCpc)

	MB: orders {LOAD,STORE}->{LOAD,STORE} (fully ordered)
	    strong transitivity (RCsc)

etc..

Also, in the above I used weak and strong transitivity, but that too is
of course up for grabs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1251356

[Multipart message — attachments visible in raw view] — view raw

On Mon, Oct 19, 2015 at 12:23:24PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 19, 2015 at 09:17:18AM +0800, Boqun Feng wrote:
> > This is confusing me right now. ;-)
> > 
> > Let's use a simple example for only one primitive, as I understand it,
> > if we say a primitive A is "fully ordered", we actually mean:
> > 
> > 1.	The memory operations preceding(in program order) A can't be
> > 	reordered after the memory operations following(in PO) A.
> > 
> > and
> > 
> > 2.	The memory operation(s) in A can't be reordered before the
> > 	memory operations preceding(in PO) A and after the memory
> > 	operations following(in PO) A.
> > 
> > If we say A is a "full barrier", we actually means:
> > 
> > 1.	The memory operations preceding(in program order) A can't be
> > 	reordered after the memory operations following(in PO) A.
> > 
> > and
> > 
> > 2.	The memory ordering guarantee in #1 is visible globally.
> > 
> > Is that correct? Or "full barrier" is more strong than I understand,
> > i.e. there is a third property of "full barrier":
> > 
> > 3.	The memory operation(s) in A can't be reordered before the
> > 	memory operations preceding(in PO) A and after the memory
> > 	operations following(in PO) A.
> > 
> > IOW, is "full barrier" a more strong version of "fully ordered" or not?
> 
> Yes, that was how I used it.
> 
> Now of course; the big question is do we want to promote this usage or
> come up with a different set of words describing this stuff.
> 
> I think separating the ordering from the transitivity is useful, for we
> can then talk about and specify them independently.
> 

Great idea! 

> That is, we can say:
> 
> 	LOAD-ACQUIRE: orders LOAD->{LOAD,STORE}
> 	              weak transitivity (RCpc)
> 
> 	MB: orders {LOAD,STORE}->{LOAD,STORE} (fully ordered)
> 	    strong transitivity (RCsc)
> 

It will be helpful if we have this kind of description for each
primitive mentioned in memory-barriers.txt, which, IMO, is better than
the description like the following:

"""
Any atomic operation that modifies some state in memory and returns information
about the state (old or new) implies an SMP-conditional general memory barrier
(smp_mb()) on each side of the actual operation (with the exception of
"""

I'm assuming that the arrow "->" stands for the program order, and word
"orders" means that a primitive guarantees some program order becomes
the memory operation order, so that the description above can be
rewritten as:

value-returning atomics:
	orders {LOAD,STORE}->RmW(atomic operation)->{LOAD,STORE}
	strong transitivity
	
much simpler and clearer for discussion and reasoning

Regards,
Boqun

> etc..
> 
> Also, in the above I used weak and strong transitivity, but that too is
> of course up for grabs.

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

#1252367

On Mon, Oct 19, 2015 at 09:17:18AM +0800, Boqun Feng wrote:
> On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote:
> > On Fri, Oct 09, 2015 at 10:31:38AM +0200, Peter Zijlstra wrote:
> [snip]
> > > 
> > > So lots of little confusions added up to complete fail :-{
> > > 
> > > Mostly I think it was the UNLOCK x + LOCK x are fully ordered (where I
> > > forgot: but not against uninvolved CPUs) and RELEASE/ACQUIRE are
> > > transitive (where I forgot: RELEASE/ACQUIRE _chains_ are transitive, but
> > > again not against uninvolved CPUs).
> > > 
> > > Which leads me to think I would like to suggest alternative rules for
> > > RELEASE/ACQUIRE (to replace those Will suggested; as I think those are
> > > partly responsible for my confusion).
> > 
> > Yeah, sorry. I originally used the phrase "fully ordered" but changed it
> > to "full barrier", which has stronger transitivity (newly understood
> > definition) requirements that I didn't intend.
> > 
> > RELEASE -> ACQUIRE should be used for message passing between two CPUs
> > and not have ordering effects on other observers unless they're part of
> > the RELEASE -> ACQUIRE chain.
> > 
> > >  - RELEASE -> ACQUIRE is fully ordered (but not a full barrier) when
> > >    they operate on the same variable and the ACQUIRE reads from the
> > >    RELEASE. Notable, RELEASE/ACQUIRE are RCpc and lack transitivity.
> > 
> > Are we explicit about the difference between "fully ordered" and "full
> > barrier" somewhere else, because this looks like it will confuse people.
> > 
> 
> This is confusing me right now. ;-)
> 
> Let's use a simple example for only one primitive, as I understand it,
> if we say a primitive A is "fully ordered", we actually mean:
> 
> 1.	The memory operations preceding(in program order) A can't be
> 	reordered after the memory operations following(in PO) A.
> 
> and
> 
> 2.	The memory operation(s) in A can't be reordered before the
> 	memory operations preceding(in PO) A and after the memory
> 	operations following(in PO) A.
> 
> If we say A is a "full barrier", we actually means:
> 
> 1.	The memory operations preceding(in program order) A can't be
> 	reordered after the memory operations following(in PO) A.
> 
> and
> 
> 2.	The memory ordering guarantee in #1 is visible globally.
> 
> Is that correct? Or "full barrier" is more strong than I understand,
> i.e. there is a third property of "full barrier":
> 
> 3.	The memory operation(s) in A can't be reordered before the
> 	memory operations preceding(in PO) A and after the memory
> 	operations following(in PO) A.
> 
> IOW, is "full barrier" a more strong version of "fully ordered" or not?

There is also the question of whether the barrier forces ordering
of unrelated stores, everything initially zero and all accesses
READ_ONCE() or WRITE_ONCE():

	P0		P1		P2		P3
	X = 1;		Y = 1;		r1 = X;		r3 = Y;
					some_barrier();	some_barrier();
					r2 = Y;		r4 = X;

P2's and P3's ordering could be globally visible without requiring
P0's and P1's independent stores to be ordered, for example, if you
used smp_rmb() for some_barrier().  In contrast, if we used smp_mb()
for barrier, everyone would agree on the order of P0's and P0's stores.

There are actually a fair number of different combinations of
aspects of memory ordering.  We will need to choose wisely.  ;-)

My hope is that the store-ordering gets folded into the globally
visible transitive level.  Especially given that I have not (yet)
seen any algorithms used in production that relied on the ordering of
independent stores.

							Thanx, Paul

> Regards,
> Boqun
> 
> > >  - RELEASE -> ACQUIRE can be upgraded to a full barrier (including
> > >    transitivity) using smp_mb__release_acquire(), either before RELEASE
> > >    or after ACQUIRE (but consistently [*]).
> > 
> > Hmm, but we don't actually need this for RELEASE -> ACQUIRE, afaict. This
> > is just needed for UNLOCK -> LOCK, and is exactly what RCU is currently
> > using (for PPC only).
> > 
> > Stepping back a second, I believe that there are three cases:
> > 
> > 
> >  RELEASE X -> ACQUIRE Y (same CPU)
> >    * Needs a barrier on TSO architectures for full ordering
> > 
> >  UNLOCK X -> LOCK Y (same CPU)
> >    * Needs a barrier on PPC for full ordering
> > 
> >  RELEASE X -> ACQUIRE X (different CPUs)
> >  UNLOCK X -> ACQUIRE X (different CPUs)
> >    * Fully ordered everywhere...
> >    * ... but needs a barrier on PPC to become a full barrier
> > 
> > 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1252550

On Tue, Oct 20, 2015 at 04:34:51PM -0700, Paul E. McKenney wrote:
> There is also the question of whether the barrier forces ordering
> of unrelated stores, everything initially zero and all accesses
> READ_ONCE() or WRITE_ONCE():
> 
> 	P0		P1		P2		P3
> 	X = 1;		Y = 1;		r1 = X;		r3 = Y;
> 					some_barrier();	some_barrier();
> 					r2 = Y;		r4 = X;
> 
> P2's and P3's ordering could be globally visible without requiring
> P0's and P1's independent stores to be ordered, for example, if you
> used smp_rmb() for some_barrier().  In contrast, if we used smp_mb()
> for barrier, everyone would agree on the order of P0's and P0's stores.

Oh!?

> There are actually a fair number of different combinations of
> aspects of memory ordering.  We will need to choose wisely.  ;-)
> 
> My hope is that the store-ordering gets folded into the globally
> visible transitive level.  Especially given that I have not (yet)
> seen any algorithms used in production that relied on the ordering of
> independent stores.

I would hope not, that's quite insane.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1253145

On Wed, Oct 21, 2015 at 10:24:52AM +0200, Peter Zijlstra wrote:
> On Tue, Oct 20, 2015 at 04:34:51PM -0700, Paul E. McKenney wrote:
> > There is also the question of whether the barrier forces ordering
> > of unrelated stores, everything initially zero and all accesses
> > READ_ONCE() or WRITE_ONCE():
> > 
> > 	P0		P1		P2		P3
> > 	X = 1;		Y = 1;		r1 = X;		r3 = Y;
> > 					some_barrier();	some_barrier();
> > 					r2 = Y;		r4 = X;
> > 
> > P2's and P3's ordering could be globally visible without requiring
> > P0's and P1's independent stores to be ordered, for example, if you
> > used smp_rmb() for some_barrier().  In contrast, if we used smp_mb()
> > for barrier, everyone would agree on the order of P0's and P0's stores.
> 
> Oh!?

Behold sequential consistency, worshipped fervently by a surprisingly
large number of people!  Something about legacy proof methods, as near
as I can tell.  ;-)

> > There are actually a fair number of different combinations of
> > aspects of memory ordering.  We will need to choose wisely.  ;-)
> > 
> > My hope is that the store-ordering gets folded into the globally
> > visible transitive level.  Especially given that I have not (yet)
> > seen any algorithms used in production that relied on the ordering of
> > independent stores.
> 
> I would hope not, that's quite insane.

Your point being?  ;-)

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1253154

On Wed, Oct 21, 2015 at 12:29:23PM -0700, Paul E. McKenney wrote:
> On Wed, Oct 21, 2015 at 10:24:52AM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 20, 2015 at 04:34:51PM -0700, Paul E. McKenney wrote:
> > > There is also the question of whether the barrier forces ordering
> > > of unrelated stores, everything initially zero and all accesses
> > > READ_ONCE() or WRITE_ONCE():
> > > 
> > > 	P0		P1		P2		P3
> > > 	X = 1;		Y = 1;		r1 = X;		r3 = Y;
> > > 					some_barrier();	some_barrier();
> > > 					r2 = Y;		r4 = X;
> > > 
> > > P2's and P3's ordering could be globally visible without requiring
> > > P0's and P1's independent stores to be ordered, for example, if you
> > > used smp_rmb() for some_barrier().  In contrast, if we used smp_mb()
> > > for barrier, everyone would agree on the order of P0's and P0's stores.
> > 
> > Oh!?
> 
> Behold sequential consistency, worshipped fervently by a surprisingly
> large number of people!  Something about legacy proof methods, as near
> as I can tell.  ;-)

But how can smp_mb() guarantee anything about P[01]? There is but the
single store, which can race against P[23] arbitrarily. There is nothing
to order.

Maybe I'm confused again..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1253164

On Wed, Oct 21, 2015 at 09:36:44PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 21, 2015 at 12:29:23PM -0700, Paul E. McKenney wrote:
> > On Wed, Oct 21, 2015 at 10:24:52AM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 20, 2015 at 04:34:51PM -0700, Paul E. McKenney wrote:
> > > > There is also the question of whether the barrier forces ordering
> > > > of unrelated stores, everything initially zero and all accesses
> > > > READ_ONCE() or WRITE_ONCE():
> > > > 
> > > > 	P0		P1		P2		P3
> > > > 	X = 1;		Y = 1;		r1 = X;		r3 = Y;
> > > > 					some_barrier();	some_barrier();
> > > > 					r2 = Y;		r4 = X;
> > > > 
> > > > P2's and P3's ordering could be globally visible without requiring
> > > > P0's and P1's independent stores to be ordered, for example, if you
> > > > used smp_rmb() for some_barrier().  In contrast, if we used smp_mb()
> > > > for barrier, everyone would agree on the order of P0's and P0's stores.
> > > 
> > > Oh!?
> > 
> > Behold sequential consistency, worshipped fervently by a surprisingly
> > large number of people!  Something about legacy proof methods, as near
> > as I can tell.  ;-)
> 
> But how can smp_mb() guarantee anything about P[01]? There is but the
> single store, which can race against P[23] arbitrarily. There is nothing
> to order.

Indeed, if your barrier is only acting locally, there is no way that
you can order the two stores.  However, some barriers act non-locally,
and this non-local action can order the stores.  This non-locality is
"cumulativity" in the PowerPC docs.

And x86 can also order P0's and P1's stores, courtesy of the "T" in "TSO".

> Maybe I'm confused again..

They say that confusion is the most productive frame of mind...

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1252993

RnJvbTogUGF1bCBFLiBNY0tlbm5leQ0KPiBTZW50OiAyMSBPY3RvYmVyIDIwMTUgMDA6MzUNCi4u
Lg0KPiBUaGVyZSBpcyBhbHNvIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHRoZSBiYXJyaWVyIGZv
cmNlcyBvcmRlcmluZw0KPiBvZiB1bnJlbGF0ZWQgc3RvcmVzLCBldmVyeXRoaW5nIGluaXRpYWxs
eSB6ZXJvIGFuZCBhbGwgYWNjZXNzZXMNCj4gUkVBRF9PTkNFKCkgb3IgV1JJVEVfT05DRSgpOg0K
PiANCj4gCVAwCQlQMQkJUDIJCVAzDQo+IAlYID0gMTsJCVkgPSAxOwkJcjEgPSBYOwkJcjMgPSBZ
Ow0KPiAJCQkJCXNvbWVfYmFycmllcigpOwlzb21lX2JhcnJpZXIoKTsNCj4gCQkJCQlyMiA9IFk7
CQlyNCA9IFg7DQo+IA0KPiBQMidzIGFuZCBQMydzIG9yZGVyaW5nIGNvdWxkIGJlIGdsb2JhbGx5
IHZpc2libGUgd2l0aG91dCByZXF1aXJpbmcNCj4gUDAncyBhbmQgUDEncyBpbmRlcGVuZGVudCBz
dG9yZXMgdG8gYmUgb3JkZXJlZCwgZm9yIGV4YW1wbGUsIGlmIHlvdQ0KPiB1c2VkIHNtcF9ybWIo
KSBmb3Igc29tZV9iYXJyaWVyKCkuICBJbiBjb250cmFzdCwgaWYgd2UgdXNlZCBzbXBfbWIoKQ0K
PiBmb3IgYmFycmllciwgZXZlcnlvbmUgd291bGQgYWdyZWUgb24gdGhlIG9yZGVyIG9mIFAwJ3Mg
YW5kIFAwJ3Mgc3RvcmVzLg0KPiANCj4gVGhlcmUgYXJlIGFjdHVhbGx5IGEgZmFpciBudW1iZXIg
b2YgZGlmZmVyZW50IGNvbWJpbmF0aW9ucyBvZg0KPiBhc3BlY3RzIG9mIG1lbW9yeSBvcmRlcmlu
Zy4gIFdlIHdpbGwgbmVlZCB0byBjaG9vc2Ugd2lzZWx5LiAgOy0pDQoNCk15IHRob3VnaHRzIG9u
IHRoaXMgYXJlIHRoYXQgbW9zdCBjb2RlIHByb2JhYmx5IGlzbid0IHBlcmZvcm1hbmNlIGNyaXRp
Y2FsDQplbm91Z2ggdG8gYmUgdXNpbmcgYW55dGhpbmcgb3RoZXIgdGhhbiBub3JtYWwgbG9ja3Mg
Zm9yIGludGVyLWNwdQ0Kc3luY2hyb25pc2F0aW9uLg0KQ2VydGFpbmx5IG1vc3QgcGVvcGxlIGFy
ZSBsaWtlbHkgdG8gZ2V0IGl0IHdyb25nIHNvbWV3aGVyZS4NClNvIHlvdSB3YW50IGEgYmlnIHJl
ZCBzdGlja2VyIHNheWluZyAnRG9uJ3QgdHJ5IHRvIGJlIHRvbyBjbGV2ZXInLg0KDQpBbHNvIHdp
dGhvdXQgZXhhbXBsZXMgb2Ygd2h5IHRoaW5ncyBnbyB3cm9uZyAoZWcgbWVtYmVyX2NvbnN1bWVy
KCkNCmFuZCBhbHBoYSkgaXQgaXMgZGlmZmljdWx0IHRvIHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVu
Y2VzIGJldHdlZW4NCmFsbCB0aGUgYmFycmllcnMgKGV0YykuDQoNCk9UT0ggZGV2aWNlIGRyaXZl
ciBjb2RlIG1heSBuZWVkIHRoaW5ncyBzbGlnaHRseSBzdHJvbmdlciB0aGFuDQpiYXJyaWVyKCkg
KHdoaWNoIEkgdGhpbmsgaXMgYXNtKDo6OiJtZW1vcnkiKSkgdG8gc2VxdWVuY2UgYWNjZXNzZXMN
CnRvIGhhcmR3YXJlIGRldmljZXMgKGFuZCBtZW1vcnkgdGhlIGhhcmR3YXJlIHJlYWRzKSwgYnV0
IHdpdGhvdXQNCmhhdmluZyBhIHN0cm9uZyBiYXJyaWVyIGluIGV2ZXJ5IGlvcmVhZC93cml0ZSgp
IGFjY2Vzcy4NCg0KCURhdmlkDQoNCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1253153

On Wed, Oct 21, 2015 at 04:04:04PM +0000, David Laight wrote:
> From: Paul E. McKenney
> > Sent: 21 October 2015 00:35
> ...
> > There is also the question of whether the barrier forces ordering
> > of unrelated stores, everything initially zero and all accesses
> > READ_ONCE() or WRITE_ONCE():
> > 
> > 	P0		P1		P2		P3
> > 	X = 1;		Y = 1;		r1 = X;		r3 = Y;
> > 					some_barrier();	some_barrier();
> > 					r2 = Y;		r4 = X;
> > 
> > P2's and P3's ordering could be globally visible without requiring
> > P0's and P1's independent stores to be ordered, for example, if you
> > used smp_rmb() for some_barrier().  In contrast, if we used smp_mb()
> > for barrier, everyone would agree on the order of P0's and P0's stores.
> > 
> > There are actually a fair number of different combinations of
> > aspects of memory ordering.  We will need to choose wisely.  ;-)
> 
> My thoughts on this are that most code probably isn't performance critical
> enough to be using anything other than normal locks for inter-cpu
> synchronisation.
> Certainly most people are likely to get it wrong somewhere.
> So you want a big red sticker saying 'Don't try to be too clever'.

I am afraid that I would run out of red stickers rather quickly,
given the large number of ways that one can shoot oneself in the
foot, even when single-threaded.

> Also without examples of why things go wrong (eg member_consumer()
> and alpha) it is difficult to understand the differences between
> all the barriers (etc).

Not just the hardware peculiarities.  It is also important to understand
the common use cases.

> OTOH device driver code may need things slightly stronger than
> barrier() (which I think is asm(:::"memory")) to sequence accesses
> to hardware devices (and memory the hardware reads), but without
> having a strong barrier in every ioread/write() access.

There are more memory models than you can shake a stick at, so yes,
we do have to choose carefully.  And yes, it does get more complex
when you add MMIO, and no, I don't know of any formal model that
takes MMIO into account.

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web