LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* f68f031d ("Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic()")
@ 2019-05-03 14:53 Paul E. McKenney
  2019-05-03 15:19 ` Peter Zijlstra
  0 siblings, 1 reply; 8+ messages in thread
From: Paul E. McKenney @ 2019-05-03 14:53 UTC (permalink / raw)
  To: stern; +Cc: linux-kernel, linux-arch, peterz

Hello, Alan,

Just following up on the -rcu commit below.  I believe that it needs
some adjustment given Peter Zijlstra's addition of "memory" to the x86
non-value-returning atomics, but thought I should double-check.

							Thanx, Paul

------------------------------------------------------------------------

commit f68f031d47f42f9fe07d9dee1ced48b2b0b8ae5e
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Apr 19 13:21:45 2019 -0400

    Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic()
    
    The description of smp_mb__before_atomic() and smp_mb__after_atomic()
    in Documentation/atomic_t.txt is slightly terse and misleading.  It
    does not clearly state that these barriers only affect the ordering of
    other instructions with respect to the atomic operation.
    
    This improves the text to make the actual ordering implications clear,
    and also to explain how these barriers differ from a RELEASE or
    ACQUIRE ordering.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>

diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt
index dca3fb0554db..d6e42d8f66de 100644
--- a/Documentation/atomic_t.txt
+++ b/Documentation/atomic_t.txt
@@ -188,7 +188,10 @@ The barriers:
   smp_mb__{before,after}_atomic()
 
 only apply to the RMW ops and can be used to augment/upgrade the ordering
-inherent to the used atomic op. These barriers provide a full smp_mb().
+inherent to the used atomic op. Unlike normal smp_mb() barriers, they order
+only the RMW op itself against the instructions preceding the
+smp_mb__before_atomic() or following the smp_mb__after_atomic(); they do
+not order instructions on the other side of the RMW op at all.
 
 These helper barriers exist because architectures have varying implicit
 ordering on their SMP atomic primitives. For example our TSO architectures
@@ -212,7 +215,8 @@ Further, while something like:
   atomic_dec(&X);
 
 is a 'typical' RELEASE pattern, the barrier is strictly stronger than
-a RELEASE. Similarly for something like:
+a RELEASE because it orders preceding instructions against both the read
+and write parts of the atomic_dec(). Similarly, something like:
 
   atomic_inc(&X);
   smp_mb__after_atomic();
@@ -244,7 +248,8 @@ strictly stronger than ACQUIRE. As illustrated:
 
 This should not happen; but a hypothetical atomic_inc_acquire() --
 (void)atomic_fetch_inc_acquire() for instance -- would allow the outcome,
-since then:
+because it would not order the W part of the RMW against the following
+WRITE_ONCE.  Thus:
 
   P1			P2
 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: f68f031d ("Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic()")
  2019-05-03 14:53 f68f031d ("Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic()") Paul E. McKenney
@ 2019-05-03 15:19 ` Peter Zijlstra
  2019-05-03 16:19   ` Alan Stern
  0 siblings, 1 reply; 8+ messages in thread
From: Peter Zijlstra @ 2019-05-03 15:19 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: stern, linux-kernel, linux-arch

On Fri, May 03, 2019 at 07:53:26AM -0700, Paul E. McKenney wrote:
> Hello, Alan,
> 
> Just following up on the -rcu commit below.  I believe that it needs
> some adjustment given Peter Zijlstra's addition of "memory" to the x86
> non-value-returning atomics, but thought I should double-check.

Right; I should get back to that thread...

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: f68f031d ("Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic()")
  2019-05-03 15:19 ` Peter Zijlstra
@ 2019-05-03 16:19   ` Alan Stern
  2019-05-03 16:34     ` Peter Zijlstra
  0 siblings, 1 reply; 8+ messages in thread
From: Alan Stern @ 2019-05-03 16:19 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Paul E. McKenney, linux-kernel, linux-arch

On Fri, 3 May 2019, Peter Zijlstra wrote:

> On Fri, May 03, 2019 at 07:53:26AM -0700, Paul E. McKenney wrote:
> > Hello, Alan,
> > 
> > Just following up on the -rcu commit below.  I believe that it needs
> > some adjustment given Peter Zijlstra's addition of "memory" to the x86
> > non-value-returning atomics, but thought I should double-check.
> 
> Right; I should get back to that thread...

The real question, still outstanding, is whether smp_mb__before_atomic 
orders anything following the RMW instruction (and similarly, whether 
smp_mb__after_atomic orders anything preceding the RMW instruction).

The other changes in that patch (i.e., the second and third hunks) are 
okay in any case, because they just flesh out an explanation that is 
already present in the text.

Alan


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: f68f031d ("Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic()")
  2019-05-03 16:19   ` Alan Stern
@ 2019-05-03 16:34     ` Peter Zijlstra
  2019-05-03 16:52       ` Alan Stern
  2019-05-03 17:13       ` [PATCH v2] Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic() Alan Stern
  0 siblings, 2 replies; 8+ messages in thread
From: Peter Zijlstra @ 2019-05-03 16:34 UTC (permalink / raw)
  To: Alan Stern; +Cc: Paul E. McKenney, linux-kernel, linux-arch

On Fri, May 03, 2019 at 12:19:21PM -0400, Alan Stern wrote:
> On Fri, 3 May 2019, Peter Zijlstra wrote:
> 
> > On Fri, May 03, 2019 at 07:53:26AM -0700, Paul E. McKenney wrote:
> > > Hello, Alan,
> > > 
> > > Just following up on the -rcu commit below.  I believe that it needs
> > > some adjustment given Peter Zijlstra's addition of "memory" to the x86
> > > non-value-returning atomics, but thought I should double-check.
> > 
> > Right; I should get back to that thread...
> 
> The real question, still outstanding, is whether smp_mb__before_atomic 
> orders anything following the RMW instruction (and similarly, whether 
> smp_mb__after_atomic orders anything preceding the RMW instruction).

Yes -- that was very much the intent, and only (some) x86 ops and (some)
MIPS config have issues with that.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: f68f031d ("Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic()")
  2019-05-03 16:34     ` Peter Zijlstra
@ 2019-05-03 16:52       ` Alan Stern
  2019-05-03 17:13       ` [PATCH v2] Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic() Alan Stern
  1 sibling, 0 replies; 8+ messages in thread
From: Alan Stern @ 2019-05-03 16:52 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Paul E. McKenney, linux-kernel, linux-arch

On Fri, 3 May 2019, Peter Zijlstra wrote:

> On Fri, May 03, 2019 at 12:19:21PM -0400, Alan Stern wrote:
> > On Fri, 3 May 2019, Peter Zijlstra wrote:
> > 
> > > On Fri, May 03, 2019 at 07:53:26AM -0700, Paul E. McKenney wrote:
> > > > Hello, Alan,
> > > > 
> > > > Just following up on the -rcu commit below.  I believe that it needs
> > > > some adjustment given Peter Zijlstra's addition of "memory" to the x86
> > > > non-value-returning atomics, but thought I should double-check.
> > > 
> > > Right; I should get back to that thread...
> > 
> > The real question, still outstanding, is whether smp_mb__before_atomic 
> > orders anything following the RMW instruction (and similarly, whether 
> > smp_mb__after_atomic orders anything preceding the RMW instruction).
> 
> Yes -- that was very much the intent, and only (some) x86 ops and (some)
> MIPS config have issues with that.

Okay, then I better update the patch.

Alan


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH v2] Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic()
  2019-05-03 16:34     ` Peter Zijlstra
  2019-05-03 16:52       ` Alan Stern
@ 2019-05-03 17:13       ` Alan Stern
  2019-05-06 16:42         ` Andrea Parri
  1 sibling, 1 reply; 8+ messages in thread
From: Alan Stern @ 2019-05-03 17:13 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: LKMM Maintainers -- Akira Yokosawa, Andrea Parri, Boqun Feng,
	Daniel Lustig, David Howells, Jade Alglave, Luc Maranget,
	Nicholas Piggin, Peter Zijlstra, Will Deacon,
	Kernel development list

The description of smp_mb__before_atomic() and smp_mb__after_atomic()
in Documentation/atomic_t.txt is slightly terse and misleading.  It
does not clearly state which other instructions are ordered by these
barriers.

This improves the text to make the actual ordering implications clear,
and also to explain how these barriers differ from a RELEASE or
ACQUIRE ordering.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Peter Zijlstra <peterz@infradead.org>

---

v2: Update the explanation: These barriers do provide order for 
accesses on the far side of the atomic RMW operation.


 Documentation/atomic_t.txt |   17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

Index: usb-devel/Documentation/atomic_t.txt
===================================================================
--- usb-devel.orig/Documentation/atomic_t.txt
+++ usb-devel/Documentation/atomic_t.txt
@@ -170,8 +170,14 @@ The barriers:
 
   smp_mb__{before,after}_atomic()
 
-only apply to the RMW ops and can be used to augment/upgrade the ordering
-inherent to the used atomic op. These barriers provide a full smp_mb().
+only apply to the RMW atomic ops and can be used to augment/upgrade the
+ordering inherent to the op. These barriers act almost like a full smp_mb():
+smp_mb__before_atomic() orders all earlier accesses against the RMW op
+itself and all accesses following it, and smp_mb__after_atomic() orders all
+later accesses against the RMW op and all accesses preceding it. However,
+accesses between the smp_mb__{before,after}_atomic() and the RMW op are not
+ordered, so it is advisable to place the barrier right next to the RMW atomic
+op whenever possible.
 
 These helper barriers exist because architectures have varying implicit
 ordering on their SMP atomic primitives. For example our TSO architectures
@@ -195,7 +201,9 @@ Further, while something like:
   atomic_dec(&X);
 
 is a 'typical' RELEASE pattern, the barrier is strictly stronger than
-a RELEASE. Similarly for something like:
+a RELEASE because it orders preceding instructions against both the read
+and write parts of the atomic_dec(), and against all following instructions
+as well. Similarly, something like:
 
   atomic_inc(&X);
   smp_mb__after_atomic();
@@ -227,7 +235,8 @@ strictly stronger than ACQUIRE. As illus
 
 This should not happen; but a hypothetical atomic_inc_acquire() --
 (void)atomic_fetch_inc_acquire() for instance -- would allow the outcome,
-since then:
+because it would not order the W part of the RMW against the following
+WRITE_ONCE.  Thus:
 
   P1			P2
 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic()
  2019-05-03 17:13       ` [PATCH v2] Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic() Alan Stern
@ 2019-05-06 16:42         ` Andrea Parri
  2019-05-12  3:28           ` Paul E. McKenney
  0 siblings, 1 reply; 8+ messages in thread
From: Andrea Parri @ 2019-05-06 16:42 UTC (permalink / raw)
  To: Alan Stern
  Cc: Paul E. McKenney, LKMM Maintainers -- Akira Yokosawa, Boqun Feng,
	Daniel Lustig, David Howells, Jade Alglave, Luc Maranget,
	Nicholas Piggin, Peter Zijlstra, Will Deacon,
	Kernel development list

On Fri, May 03, 2019 at 01:13:44PM -0400, Alan Stern wrote:
> The description of smp_mb__before_atomic() and smp_mb__after_atomic()
> in Documentation/atomic_t.txt is slightly terse and misleading.  It
> does not clearly state which other instructions are ordered by these
> barriers.
> 
> This improves the text to make the actual ordering implications clear,
> and also to explain how these barriers differ from a RELEASE or
> ACQUIRE ordering.
> 
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> CC: Peter Zijlstra <peterz@infradead.org>

I understand that this does indeed better describe the intended semantics:

Acked-by: Andrea Parri <andrea.parri@amarulasolutions.com>

Now we would only need to fix the implementations and a few (mis)uses. ;-)

  Andrea


> 
> ---
> 
> v2: Update the explanation: These barriers do provide order for 
> accesses on the far side of the atomic RMW operation.
> 
> 
>  Documentation/atomic_t.txt |   17 +++++++++++++----
>  1 file changed, 13 insertions(+), 4 deletions(-)
> 
> Index: usb-devel/Documentation/atomic_t.txt
> ===================================================================
> --- usb-devel.orig/Documentation/atomic_t.txt
> +++ usb-devel/Documentation/atomic_t.txt
> @@ -170,8 +170,14 @@ The barriers:
>  
>    smp_mb__{before,after}_atomic()
>  
> -only apply to the RMW ops and can be used to augment/upgrade the ordering
> -inherent to the used atomic op. These barriers provide a full smp_mb().
> +only apply to the RMW atomic ops and can be used to augment/upgrade the
> +ordering inherent to the op. These barriers act almost like a full smp_mb():
> +smp_mb__before_atomic() orders all earlier accesses against the RMW op
> +itself and all accesses following it, and smp_mb__after_atomic() orders all
> +later accesses against the RMW op and all accesses preceding it. However,
> +accesses between the smp_mb__{before,after}_atomic() and the RMW op are not
> +ordered, so it is advisable to place the barrier right next to the RMW atomic
> +op whenever possible.
>  
>  These helper barriers exist because architectures have varying implicit
>  ordering on their SMP atomic primitives. For example our TSO architectures
> @@ -195,7 +201,9 @@ Further, while something like:
>    atomic_dec(&X);
>  
>  is a 'typical' RELEASE pattern, the barrier is strictly stronger than
> -a RELEASE. Similarly for something like:
> +a RELEASE because it orders preceding instructions against both the read
> +and write parts of the atomic_dec(), and against all following instructions
> +as well. Similarly, something like:
>  
>    atomic_inc(&X);
>    smp_mb__after_atomic();
> @@ -227,7 +235,8 @@ strictly stronger than ACQUIRE. As illus
>  
>  This should not happen; but a hypothetical atomic_inc_acquire() --
>  (void)atomic_fetch_inc_acquire() for instance -- would allow the outcome,
> -since then:
> +because it would not order the W part of the RMW against the following
> +WRITE_ONCE.  Thus:
>  
>    P1			P2
>  
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic()
  2019-05-06 16:42         ` Andrea Parri
@ 2019-05-12  3:28           ` Paul E. McKenney
  0 siblings, 0 replies; 8+ messages in thread
From: Paul E. McKenney @ 2019-05-12  3:28 UTC (permalink / raw)
  To: Andrea Parri
  Cc: Alan Stern, LKMM Maintainers -- Akira Yokosawa, Boqun Feng,
	Daniel Lustig, David Howells, Jade Alglave, Luc Maranget,
	Nicholas Piggin, Peter Zijlstra, Will Deacon,
	Kernel development list

On Mon, May 06, 2019 at 06:42:38PM +0200, Andrea Parri wrote:
> On Fri, May 03, 2019 at 01:13:44PM -0400, Alan Stern wrote:
> > The description of smp_mb__before_atomic() and smp_mb__after_atomic()
> > in Documentation/atomic_t.txt is slightly terse and misleading.  It
> > does not clearly state which other instructions are ordered by these
> > barriers.
> > 
> > This improves the text to make the actual ordering implications clear,
> > and also to explain how these barriers differ from a RELEASE or
> > ACQUIRE ordering.
> > 
> > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > CC: Peter Zijlstra <peterz@infradead.org>
> 
> I understand that this does indeed better describe the intended semantics:
> 
> Acked-by: Andrea Parri <andrea.parri@amarulasolutions.com>

I reverted the original and applied this one.  It will become visible
at the next rebase.

> Now we would only need to fix the implementations and a few (mis)uses. ;-)

You do have a start on this task!  ;-)

							Thanx, Paul

>   Andrea
> 
> 
> > 
> > ---
> > 
> > v2: Update the explanation: These barriers do provide order for 
> > accesses on the far side of the atomic RMW operation.
> > 
> > 
> >  Documentation/atomic_t.txt |   17 +++++++++++++----
> >  1 file changed, 13 insertions(+), 4 deletions(-)
> > 
> > Index: usb-devel/Documentation/atomic_t.txt
> > ===================================================================
> > --- usb-devel.orig/Documentation/atomic_t.txt
> > +++ usb-devel/Documentation/atomic_t.txt
> > @@ -170,8 +170,14 @@ The barriers:
> >  
> >    smp_mb__{before,after}_atomic()
> >  
> > -only apply to the RMW ops and can be used to augment/upgrade the ordering
> > -inherent to the used atomic op. These barriers provide a full smp_mb().
> > +only apply to the RMW atomic ops and can be used to augment/upgrade the
> > +ordering inherent to the op. These barriers act almost like a full smp_mb():
> > +smp_mb__before_atomic() orders all earlier accesses against the RMW op
> > +itself and all accesses following it, and smp_mb__after_atomic() orders all
> > +later accesses against the RMW op and all accesses preceding it. However,
> > +accesses between the smp_mb__{before,after}_atomic() and the RMW op are not
> > +ordered, so it is advisable to place the barrier right next to the RMW atomic
> > +op whenever possible.
> >  
> >  These helper barriers exist because architectures have varying implicit
> >  ordering on their SMP atomic primitives. For example our TSO architectures
> > @@ -195,7 +201,9 @@ Further, while something like:
> >    atomic_dec(&X);
> >  
> >  is a 'typical' RELEASE pattern, the barrier is strictly stronger than
> > -a RELEASE. Similarly for something like:
> > +a RELEASE because it orders preceding instructions against both the read
> > +and write parts of the atomic_dec(), and against all following instructions
> > +as well. Similarly, something like:
> >  
> >    atomic_inc(&X);
> >    smp_mb__after_atomic();
> > @@ -227,7 +235,8 @@ strictly stronger than ACQUIRE. As illus
> >  
> >  This should not happen; but a hypothetical atomic_inc_acquire() --
> >  (void)atomic_fetch_inc_acquire() for instance -- would allow the outcome,
> > -since then:
> > +because it would not order the W part of the RMW against the following
> > +WRITE_ONCE.  Thus:
> >  
> >    P1			P2
> >  
> > 
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2019-05-12  3:28 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-03 14:53 f68f031d ("Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic()") Paul E. McKenney
2019-05-03 15:19 ` Peter Zijlstra
2019-05-03 16:19   ` Alan Stern
2019-05-03 16:34     ` Peter Zijlstra
2019-05-03 16:52       ` Alan Stern
2019-05-03 17:13       ` [PATCH v2] Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic() Alan Stern
2019-05-06 16:42         ` Andrea Parri
2019-05-12  3:28           ` Paul E. McKenney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).