* 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
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
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()
>
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()
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 @@
* 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 thus
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
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
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
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 +++
>
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
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 {
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 { \
Subject: arch: Introduce smp_load_acquire(), smp_store_release()
From: Peter Zijlstra pet...@infradead.org
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
On Wed, Nov 6, 2013 at 1:39 PM, Peter Zijlstra pet...@infradead.org 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
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
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 fully
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 paul...@linux.vnet.ibm.com
Thanks, I think I'll
On Tue, Nov 05, 2013 at 02:05:48PM +, Will Deacon wrote:
> > > +
> > > +#define smp_store_release(p, v)
> > > \
> > > +do { \
> > > + smp_mb();
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
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
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
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 ifdefs
On Tue, Nov 05, 2013 at 02:05:48PM +, Will Deacon wrote:
+
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb();
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... :-/
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()
> >
> >
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 +++
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,
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.
>
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
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
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 { \
>
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
>
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
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
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 another cpu, and
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.
This is
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 above
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 +++
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()
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... :-/
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
paul...@linux.vnet.ibm.com wrote:
smp_storebuffer_mb() -- A barrier that enforces those orderings
that do not invalidate the hardware store-buffer optimization.
Ugh.
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 barrier,
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 { \
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
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,
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
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
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
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 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
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
On Sun, Nov 3, 2013 at 7:17 AM, Peter Zijlstra pet...@infradead.org 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
On Sun, Nov 03, 2013 at 10:08:14AM -0800, Linus Torvalds wrote:
On Sun, Nov 3, 2013 at 7:17 AM, Peter Zijlstra pet...@infradead.org 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
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 mfence on
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 pet...@infradead.org wrote:
On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote:
If there was an
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
On Sun, Nov 3, 2013 at 2:42 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com 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
58 matches
Mail list logo
