Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-07 Thread Mathieu Desnoyers
* Peter Zijlstra (pet...@infradead.org) wrote: [...] Hi Peter, Looking at this simplified version of perf's ring buffer synchronization, I get concerned about the following issue: > /* > * One important detail is that the kbuf part and the kbuf_writer() are > * strictly per cpu and we can thu

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-07 Thread Peter Zijlstra
On Thu, Nov 07, 2013 at 11:17:41AM +, Will Deacon wrote: > Hi Peter, > > Couple of minor fixes on the arm64 side... > > On Wed, Nov 06, 2013 at 01:57:36PM +, Peter Zijlstra wrote: > > --- a/arch/arm64/include/asm/barrier.h > > +++ b/arch/arm64/include/asm/barrier.h > > @@ -35,11 +35,59 @@

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-07 Thread Will Deacon
Hi Peter, Couple of minor fixes on the arm64 side... On Wed, Nov 06, 2013 at 01:57:36PM +, Peter Zijlstra wrote: > --- a/arch/arm64/include/asm/barrier.h > +++ b/arch/arm64/include/asm/barrier.h > @@ -35,11 +35,59 @@ > #define smp_mb() barrier() > #define smp_rmb() barrier() > #

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-06 Thread Peter Zijlstra
On Wed, Nov 06, 2013 at 10:48:48AM -0800, Paul E. McKenney wrote: > A few nits on Documentation/memory-barriers.txt and some pointless > comments elsewhere. With the suggested Documentation/memory-barriers.txt > fixes: > > Reviewed-by: Paul E. McKenney Thanks, I think I'll cut the thing into a

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-06 Thread Paul E. McKenney
On Wed, Nov 06, 2013 at 02:57:36PM +0100, Peter Zijlstra wrote: > On Wed, Nov 06, 2013 at 01:51:10PM +0100, Geert Uytterhoeven wrote: > > This is screaming for a default implementation in asm-generic. > > Right you are... how about a little something like this? > > There's a few archs I didn't fu

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-06 Thread Peter Zijlstra
On Wed, Nov 06, 2013 at 01:51:10PM +0100, Geert Uytterhoeven wrote: > This is screaming for a default implementation in asm-generic. Right you are... how about a little something like this? There's a few archs I didn't fully merge with the generic one because of weird nop implementations. asm vo

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-06 Thread Geert Uytterhoeven
On Wed, Nov 6, 2013 at 1:39 PM, Peter Zijlstra wrote: > Documentation/memory-barriers.txt | 157 > +- > arch/alpha/include/asm/barrier.h | 15 +++ > arch/arc/include/asm/barrier.h| 15 +++ > arch/arm/include/asm/barrier.h| 15 +++ >

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-06 Thread Peter Zijlstra
Subject: arch: Introduce smp_load_acquire(), smp_store_release() From: Peter Zijlstra Date: Mon, 4 Nov 2013 20:18:11 +0100 A number of situations currently require the heavyweight smp_mb(), even though there is no need to order prior stores against later loads. Many architectures have much chea

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-06 Thread Will Deacon
On Tue, Nov 05, 2013 at 06:49:43PM +, Peter Zijlstra wrote: > On Tue, Nov 05, 2013 at 02:05:48PM +, Will Deacon wrote: > > > > + > > > > +#define smp_store_release(p, v) > > > > \ > > > > +do {

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-05 Thread Peter Zijlstra
On Tue, Nov 05, 2013 at 02:05:48PM +, Will Deacon wrote: > > > + > > > +#define smp_store_release(p, v) > > > \ > > > +do { \ > > > + smp_mb();

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-05 Thread Paul E. McKenney
On Tue, Nov 05, 2013 at 02:05:48PM +, Will Deacon wrote: > On Mon, Nov 04, 2013 at 08:53:44PM +, Paul E. McKenney wrote: > > On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote: > > Some comments below. I believe that opcodes need to be fixed for IA64. > > I am unsure of the ifd

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-05 Thread Will Deacon
On Mon, Nov 04, 2013 at 08:53:44PM +, Paul E. McKenney wrote: > On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote: > Some comments below. I believe that opcodes need to be fixed for IA64. > I am unsure of the ifdefs and opcodes for arm64, but the ARM folks should > be able to tell

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-04 Thread Paul E. McKenney
On Mon, Nov 04, 2013 at 08:18:11PM +0100, Peter Zijlstra wrote: > On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote: > > +#define smp_load_acquire(p, v) > > \ > > I R idiot!! :-) OK, I did miss this one as well... :-/

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-04 Thread Paul E. McKenney
On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote: > On Mon, Nov 04, 2013 at 08:27:32AM -0800, Paul E. McKenney wrote: > > All this is leading me to suggest the following shortenings of names: > > > > smp_load_with_acquire_semantics() -> smp_load_acquire() > > > > smp_store_w

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-04 Thread Peter Zijlstra
On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote: > +#define smp_load_acquire(p, v) > \ I R idiot!! :-) --- arch/alpha/include/asm/barrier.h | 13 +++ arch/arc/include/asm/barrier.h| 13 +++ arch/arm/includ

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-04 Thread Peter Zijlstra
On Mon, Nov 04, 2013 at 08:27:32AM -0800, Paul E. McKenney wrote: > All this is leading me to suggest the following shortenings of names: > > smp_load_with_acquire_semantics() -> smp_load_acquire() > > smp_store_with_release_semantics() -> smp_store_release() > > But names aside, the

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-04 Thread Paul E. McKenney
On Mon, Nov 04, 2013 at 11:05:53AM +, Will Deacon wrote: > On Sun, Nov 03, 2013 at 11:34:00PM +, Linus Torvalds wrote: > > So it would *kind* of act like a "smp_wmb() + smp_rmb()", but the > > problem is that a "smp_rmb()" doesn't really "attach" to the preceding > > write. > > Agreed. >

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-04 Thread Peter Zijlstra
On Mon, Nov 04, 2013 at 08:27:32AM -0800, Paul E. McKenney wrote: > > > > > > /* > > * One important detail is that the kbuf part and the kbuf_writer() are > > * strictly per cpu and we can thus rely on program order for those. > > * > > * Only the userspace consumer can possibly run on anoth

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-04 Thread Paul E. McKenney
On Mon, Nov 04, 2013 at 12:22:54PM +0100, Peter Zijlstra wrote: > On Mon, Nov 04, 2013 at 02:51:00AM -0800, Paul E. McKenney wrote: > > OK, something like this for the definitions (though PowerPC might want > > to locally abstract the lwsync expansion): > > > > #define smp_store_with_release_s

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-04 Thread Peter Zijlstra
On Mon, Nov 04, 2013 at 02:51:00AM -0800, Paul E. McKenney wrote: > OK, something like this for the definitions (though PowerPC might want > to locally abstract the lwsync expansion): > > #define smp_store_with_release_semantics(p, v) /* x86, s390, etc. */ \ > do { \ > ba

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-04 Thread Will Deacon
On Sun, Nov 03, 2013 at 11:34:00PM +, Linus Torvalds wrote: > So it would *kind* of act like a "smp_wmb() + smp_rmb()", but the > problem is that a "smp_rmb()" doesn't really "attach" to the preceding > write. Agreed. > This is analogous to a "acquire" operation: you cannot make an > "acquire

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-04 Thread Paul E. McKenney
On Sun, Nov 03, 2013 at 03:34:00PM -0800, Linus Torvalds wrote: > On Sun, Nov 3, 2013 at 2:42 PM, Paul E. McKenney > wrote: > > > > smp_storebuffer_mb() -- A barrier that enforces those orderings > > that do not invalidate the hardware store-buffer optimization. > > Ugh. Maybe. Can you gu

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-03 Thread Linus Torvalds
On Sun, Nov 3, 2013 at 2:42 PM, Paul E. McKenney wrote: > > smp_storebuffer_mb() -- A barrier that enforces those orderings > that do not invalidate the hardware store-buffer optimization. Ugh. Maybe. Can you guarantee that those are the correct semantics? And why talk about the hardware

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-03 Thread Paul E. McKenney
On Mon, Nov 04, 2013 at 07:59:23AM +1100, Benjamin Herrenschmidt wrote: > On Sun, 2013-11-03 at 16:17 +0100, Peter Zijlstra wrote: > > On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote: > > > If there was an smp_tmb(), I would likely use it in rcu_assign_pointer(). > > > > Well, I'm

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-03 Thread Paul E. McKenney
On Sun, Nov 03, 2013 at 09:01:24PM +0100, Peter Zijlstra wrote: > On Sun, Nov 03, 2013 at 10:08:14AM -0800, Linus Torvalds wrote: > > On Sun, Nov 3, 2013 at 7:17 AM, Peter Zijlstra wrote: > > > On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote: > > >> If there was an smp_tmb(), I wo

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-03 Thread Benjamin Herrenschmidt
On Sun, 2013-11-03 at 16:17 +0100, Peter Zijlstra wrote: > On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote: > > If there was an smp_tmb(), I would likely use it in rcu_assign_pointer(). > > Well, I'm obviously all for introducing this new barrier, for it will > reduce a full mfenc

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-03 Thread Peter Zijlstra
On Sun, Nov 03, 2013 at 10:08:14AM -0800, Linus Torvalds wrote: > On Sun, Nov 3, 2013 at 7:17 AM, Peter Zijlstra wrote: > > On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote: > >> If there was an smp_tmb(), I would likely use it in rcu_assign_pointer(). > > > > Well, I'm obviously a

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-03 Thread Linus Torvalds
On Sun, Nov 3, 2013 at 7:17 AM, Peter Zijlstra wrote: > On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote: >> If there was an smp_tmb(), I would likely use it in rcu_assign_pointer(). > > Well, I'm obviously all for introducing this new barrier, for it will > reduce a full mfence on

[RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-03 Thread Peter Zijlstra
On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote: > If there was an smp_tmb(), I would likely use it in rcu_assign_pointer(). Well, I'm obviously all for introducing this new barrier, for it will reduce a full mfence on x86 to a compiler barrier. And ppc can use lwsync as opposed t