Hi Davidlohr,
On 10/10/19 9:25 PM, Davidlohr Bueso wrote:
On Thu, 10 Oct 2019, Peter Zijlstra wrote:
On Thu, Oct 10, 2019 at 02:13:47PM +0200, Manfred Spraul wrote:
Therefore smp_mb__{before,after}_atomic() may be combined with
cmpxchg_relaxed, to form a full memory barrier, on all archs.
Just so.
We might want something like this?
----8<---------------------------------------------------------
From: Davidlohr Bueso <d...@stgolabs.net>
Subject: [PATCH] Documentation/memory-barriers.txt: Mention
smp_mb__{before,after}_atomic() and CAS
Explicitly mention possible usages to guarantee serialization even upon
failed cmpxchg (or similar) calls along with
smp_mb__{before,after}_atomic().
Signed-off-by: Davidlohr Bueso <dbu...@suse.de>
---
Documentation/memory-barriers.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index 1adbb8a371c7..5d2873d4b442 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1890,6 +1890,18 @@ There are some more advanced barrier functions:
This makes sure that the death mark on the object is perceived to
be set
*before* the reference counter is decremented.
+ Similarly, these barriers can be used to guarantee serialization
for atomic
+ RMW calls on architectures which may not imply memory barriers
upon failure.
+
+ obj->next = NULL;
+ smp_mb__before_atomic()
+ if (cmpxchg(&obj->ptr, NULL, val))
+ return;
+
+ This makes sure that the store to the next pointer always has
smp_store_mb()
+ semantics. As such, smp_mb__{before,after}_atomic() calls allow
optimizing
+ the barrier usage by finer grained serialization.
+
See Documentation/atomic_{t,bitops}.txt for more information.
I don't know. The new documentation would not have answered my question
(is it ok to combine smp_mb__before_atomic() with atomic_relaxed()?).
And it copies content already present in atomic_t.txt.
Thus: I would prefer if the first sentence of the paragraph is replaced:
The list of operations should end with "...", and it should match what
is in atomic_t.txt
Ok?
--
Manfred
>From 8df60211228042672ba0cd89c3566c5145e8b203 Mon Sep 17 00:00:00 2001
From: Manfred Spraul <manf...@colorfullife.com>
Date: Fri, 11 Oct 2019 10:33:26 +0200
Subject: [PATCH 4/4] Documentation/memory-barriers.txt: Clarify cmpxchg()
The documentation in memory-barriers.txt claims that
smp_mb__{before,after}_atomic() are for atomic ops that do not return a
value.
This is misleading and doesn't match the example in atomic_t.txt,
and e.g. smp_mb__before_atomic() may and is used together with
cmpxchg_relaxed() in the wake_q code.
The purpose of e.g. smp_mb__before_atomic() is to "upgrade" a following
RMW atomic operation to a full memory barrier.
The return code of the atomic operation has no impact, so all of the
following examples are valid:
1)
smp_mb__before_atomic();
atomic_add();
2)
smp_mb__before_atomic();
atomic_xchg_relaxed();
3)
smp_mb__before_atomic();
atomic_fetch_add_relaxed();
Invalid would be:
smp_mb__before_atomic();
atomic_set();
Signed-off-by: Manfred Spraul <manf...@colorfullife.com>
Cc: Waiman Long <long...@redhat.com>
Cc: Davidlohr Bueso <d...@stgolabs.net>
Cc: Peter Zijlstra <pet...@infradead.org>
---
Documentation/memory-barriers.txt | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 1adbb8a371c7..52076b057400 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1873,12 +1873,13 @@ There are some more advanced barrier functions:
(*) smp_mb__before_atomic();
(*) smp_mb__after_atomic();
- These are for use with atomic (such as add, subtract, increment and
- decrement) functions that don't return a value, especially when used for
- reference counting. These functions do not imply memory barriers.
+ These are for use with atomic RMW functions (such as add, subtract,
+ increment, decrement, failed conditional operations, ...) that do
+ not imply memory barriers, but where the code needs a memory barrier,
+ for example when used for reference counting.
- These are also used for atomic bitop functions that do not return a
- value (such as set_bit and clear_bit).
+ These are also used for atomic RMW bitop functions that do imply a full
+ memory barrier (such as set_bit and clear_bit).
As an example, consider a piece of code that marks an object as being dead
and then decrements the object's reference count:
--
2.21.0
