Hi all,
This is v5 of the series.
Link for v1: https://lkml.org/lkml/2015/8/27/798
Link for v2: https://lkml.org/lkml/2015/9/16/527
Link for v3: https://lkml.org/lkml/2015/10/12/368
Link for v4: https://lkml.org/lkml/2015/10/14/670
Changes since v4:
* define PPC_ATOMIC_ENTRY_BARRIER as "sync" (Paul E. Mckenney)
* remove PPC-specific __atomic_op_fence().
Relaxed/acquire/release variants of atomic operations {add,sub}_return
and {cmp,}xchg are introduced by commit:
"atomics: add acquire/release/relaxed variants of some atomic operations"
and {inc,dec}_return has been introduced by commit:
"locking/asm-generic: Add _{relaxed|acquire|release}() variants for
inc/dec atomics"
Both of these are in the current locking/core branch of the tip tree.
By default, the generic code will implement a relaxed variant as a full
ordered atomic operation and release/acquire a variant as a relaxed
variant with a necessary general barrier before or after.
On PPC, which has a weak memory order model, a relaxed variant can be
implemented more lightweightly than a full ordered one. Further more, release
and acquire variants can be implemented with arch-specific lightweight
barriers.
Besides, cmpxchg, xchg and their atomic_ versions are only RELEASE+ACQUIRE
rather that fully ordered in current PPC implementation, which is incorrect
according to memory-barriers.txt. Further more, PPC_ATOMIC_ENTRY_BARRIER, the
leading barrier of fully ordered atomics, should be "sync" rather than "lwsync"
if SMP=y, to guarantee fully ordered semantics.
Therefore this patchset fixes the order guarantee of cmpxchg, xchg and
value-returning atomics on PPC and implements the relaxed/acquire/release
variants based on PPC memory model and specific barriers, Some trivial tests
for these new variants are also included in this series, because some of these
variants are not used in kernel for now, I think is a good idea to at least
generate the code for these variants somewhere.
The patchset consists of 6 parts:
1. Make value-returning atomics, futex atomics, xchg and cmpxchg fully
ordered
2. Add trivial tests for the new variants in lib/atomic64_test.c
3. Allow architectures to define their own __atomic_op_*() helpers
to build other variants based on relaxed.
4. Implement atomic{,64}_{add,sub,inc,dec}_return_* variants
5. Implement xchg_* and atomic{,64}_xchg_* variants
6. Implement cmpxchg_* atomic{,64}_cmpxchg_* variants
This patchset is based on current locking/core branch of the tip tree
and all patches are built and boot tested for little endian pseries, and
also tested by 0day.
Looking forward to any suggestion, question and comment ;-)
Regards,
Boqun
This patch fixes two problems to make value-returning atomics and
{cmp}xchg fully ordered on PPC.
According to memory-barriers.txt:
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 ...
which means these operations should be fully ordered. However on PPC,
PPC_ATOMIC_ENTRY_BARRIER is the barrier before the actual operation,
which is currently "lwsync" if SMP=y. The leading "lwsync" can not
guarantee fully ordered atomics, according to Paul Mckenney:
https://lkml.org/lkml/2015/10/14/970
To fix this, we define PPC_ATOMIC_ENTRY_BARRIER as "sync" to guarantee
the fully-ordered semantics.
This also makes futex atomics fully ordered, which can avoid possible
memory ordering problems if userspace code relies on futex system call
for fully ordered semantics.
Another thing to fix is that xchg, cmpxchg and their atomic{64}_
versions are currently RELEASE+ACQUIRE, which are not fully ordered.
So also replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
PPC_ATOMIC_ENTRY_BARRIER and PPC_ATOMIC_EXIT_BARRIER in
__{cmp,}xchg_{u32,u64} respectively to guarantee fully ordered semantics
of atomic{,64}_{cmp,}xchg() and {cmp,}xchg(), as a complement of commit
b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics").
Cc: <redacted> # 3.4+
Signed-off-by: Boqun Feng <redacted>
---
Michael, I also change PPC_ATOMIC_ENTRY_BARRIER as "sync" if SMP=y in this
version , which is different from the previous one, so request for a new ack.
Thank you ;-)
arch/powerpc/include/asm/cmpxchg.h | 16 ++++++++--------
arch/powerpc/include/asm/synch.h | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
Some atomic operations now have _relaxed/acquire/release variants, this
patch then adds some trivial tests for two purpose:
1. test the behavior of these new operations in single-CPU
environment.
2. make their code generated before we actually use them somewhere,
so that we can examine their assembly code.
Signed-off-by: Boqun Feng <redacted>
---
lib/atomic64_test.c | 120 ++++++++++++++++++++++++++++++++++------------------
1 file changed, 79 insertions(+), 41 deletions(-)
Some architectures may have their special barriers for acquire, release
and fence semantics, so that general memory barriers(smp_mb__*_atomic())
in the default __atomic_op_*() may be too strong, so allow architectures
to define their own helpers which can overwrite the default helpers.
Signed-off-by: Boqun Feng <redacted>
---
include/linux/atomic.h | 10 ++++++++++
1 file changed, 10 insertions(+)
Implement xchg_relaxed and atomic{,64}_xchg_relaxed, based on these
_relaxed variants, release/acquire variants and fully ordered versions
can be built.
Note that xchg_relaxed and atomic_{,64}_xchg_relaxed are not compiler
barriers.
Signed-off-by: Boqun Feng <redacted>
---
arch/powerpc/include/asm/atomic.h | 2 ++
arch/powerpc/include/asm/cmpxchg.h | 69 +++++++++++++++++---------------------
2 files changed, 32 insertions(+), 39 deletions(-)
On powerpc, acquire and release semantics can be achieved with
lightweight barriers("lwsync" and "ctrl+isync"), which can be used to
implement __atomic_op_{acquire,release}.
For release semantics, since we only need to ensure all memory accesses
that issue before must take effects before the -store- part of the
atomics, "lwsync" is what we only need. On the platform without
"lwsync", "sync" should be used. Therefore, smp_lwsync() is used here.
For acquire semantics, "lwsync" is what we only need for the similar
reason. However on the platform without "lwsync", we can use "isync"
rather than "sync" as an acquire barrier. Therefore in
__atomic_op_acquire() we use PPC_ACQUIRE_BARRIER, which is barrier() on
UP, "lwsync" if available and "isync" otherwise.
Implement atomic{,64}_{add,sub,inc,dec}_return_relaxed, and build other
variants with these helpers.
Signed-off-by: Boqun Feng <redacted>
---
arch/powerpc/include/asm/atomic.h | 107 +++++++++++++++++++++++---------------
1 file changed, 65 insertions(+), 42 deletions(-)
Implement cmpxchg{,64}_relaxed and atomic{,64}_cmpxchg_relaxed, based on
which _release variants can be built.
To avoid superfluous barriers in _acquire variants, we implement these
operations with assembly code rather use __atomic_op_acquire() to build
them automatically.
For the same reason, we keep the assembly implementation of fully
ordered cmpxchg operations.
However, we don't do the similar for _release, because that will require
putting barriers in the middle of ll/sc loops, which is probably a bad
idea.
Note cmpxchg{,64}_relaxed and atomic{,64}_cmpxchg_relaxed are not
compiler barriers.
Signed-off-by: Boqun Feng <redacted>
---
arch/powerpc/include/asm/atomic.h | 10 +++
arch/powerpc/include/asm/cmpxchg.h | 149 ++++++++++++++++++++++++++++++++++++-
2 files changed, 158 insertions(+), 1 deletion(-)
On Mon, Oct 26, 2015 at 05:50:52PM +0800, Boqun Feng wrote:
This patch fixes two problems to make value-returning atomics and
{cmp}xchg fully ordered on PPC.
According to memory-barriers.txt:
quoted
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 ...
which means these operations should be fully ordered. However on PPC,
PPC_ATOMIC_ENTRY_BARRIER is the barrier before the actual operation,
which is currently "lwsync" if SMP=y. The leading "lwsync" can not
guarantee fully ordered atomics, according to Paul Mckenney:
https://lkml.org/lkml/2015/10/14/970
To fix this, we define PPC_ATOMIC_ENTRY_BARRIER as "sync" to guarantee
the fully-ordered semantics.
This also makes futex atomics fully ordered, which can avoid possible
memory ordering problems if userspace code relies on futex system call
for fully ordered semantics.
Another thing to fix is that xchg, cmpxchg and their atomic{64}_
versions are currently RELEASE+ACQUIRE, which are not fully ordered.
So also replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
PPC_ATOMIC_ENTRY_BARRIER and PPC_ATOMIC_EXIT_BARRIER in
__{cmp,}xchg_{u32,u64} respectively to guarantee fully ordered semantics
of atomic{,64}_{cmp,}xchg() and {cmp,}xchg(), as a complement of commit
b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics").
Cc: <redacted> # 3.4+
Hmm.. I use the same Cc tag as v4, seems my git(2.6.2) send-email has a
weird behavior of composing Cc address?
I will resend this one soon, sorry ;-(
Regards,
Boqun
quoted hunk
Signed-off-by: Boqun Feng <redacted>
---
Michael, I also change PPC_ATOMIC_ENTRY_BARRIER as "sync" if SMP=y in this
version , which is different from the previous one, so request for a new ack.
Thank you ;-)
arch/powerpc/include/asm/cmpxchg.h | 16 ++++++++--------
arch/powerpc/include/asm/synch.h | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
This patch fixes two problems to make value-returning atomics and
{cmp}xchg fully ordered on PPC.
According to memory-barriers.txt:
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 ...
which means these operations should be fully ordered. However on PPC,
PPC_ATOMIC_ENTRY_BARRIER is the barrier before the actual operation,
which is currently "lwsync" if SMP=y. The leading "lwsync" can not
guarantee fully ordered atomics, according to Paul Mckenney:
https://lkml.org/lkml/2015/10/14/970
To fix this, we define PPC_ATOMIC_ENTRY_BARRIER as "sync" to guarantee
the fully-ordered semantics.
This also makes futex atomics fully ordered, which can avoid possible
memory ordering problems if userspace code relies on futex system call
for fully ordered semantics.
Another thing to fix is that xchg, cmpxchg and their atomic{64}_
versions are currently RELEASE+ACQUIRE, which are not fully ordered.
So also replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
PPC_ATOMIC_ENTRY_BARRIER and PPC_ATOMIC_EXIT_BARRIER in
__{cmp,}xchg_{u32,u64} respectively to guarantee fully ordered semantics
of atomic{,64}_{cmp,}xchg() and {cmp,}xchg(), as a complement of commit
b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics").
Cc: <redacted> # 3.4+
Signed-off-by: Boqun Feng <redacted>
---
Michael, I also change PPC_ATOMIC_ENTRY_BARRIER as "sync" if SMP=y in this
version , which is different from the previous one, so request for a new ack.
Thank you ;-)
arch/powerpc/include/asm/cmpxchg.h | 16 ++++++++--------
arch/powerpc/include/asm/synch.h | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2015-10-27 02:33:52
On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote:
This patch fixes two problems to make value-returning atomics and
{cmp}xchg fully ordered on PPC.
Hi Boqun,
Can you please split this into two patches. One that does the cmpxchg change
and one that changes PPC_ATOMIC_ENTRY_BARRIER.
Also given how pervasive this change is I'd like to take it via the powerpc
next tree, so can you please send this patch (which will be two after you split
it) as powerpc patches. And the rest can go via tip?
cheers
On Tue, Oct 27, 2015 at 01:33:47PM +1100, Michael Ellerman wrote:
On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote:
quoted
This patch fixes two problems to make value-returning atomics and
{cmp}xchg fully ordered on PPC.
Hi Boqun,
Can you please split this into two patches. One that does the cmpxchg change
and one that changes PPC_ATOMIC_ENTRY_BARRIER.
OK, make sense ;-)
Also given how pervasive this change is I'd like to take it via the powerpc
next tree, so can you please send this patch (which will be two after you split
it) as powerpc patches. And the rest can go via tip?
One problem is that patch 5 will remove __xchg_u32 and __xchg_64
entirely, which are modified in this patch(patch 1), so there will be
some conflicts if two branch get merged, I think.
Alternative way is that all this series go to powerpc next tree as most
of the dependent patches are already there. I just need to remove
inc/dec related code and resend them when appropriate. Besides, I can
pull patch 2 out and send it as a tip patch because it's general code
and no one depends on this in this series.
To summerize:
patch 1(split to two), 3, 4(remove inc/dec implementation), 5, 6 sent as
powerpc patches for powerpc next, patch 2(unmodified) sent as tip patch
for locking/core.
Peter and Michael, this works for you both?
Regards,
On Tue, Oct 27, 2015 at 11:06:52AM +0800, Boqun Feng wrote:
On Tue, Oct 27, 2015 at 01:33:47PM +1100, Michael Ellerman wrote:
quoted
On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote:
quoted
This patch fixes two problems to make value-returning atomics and
{cmp}xchg fully ordered on PPC.
Hi Boqun,
Can you please split this into two patches. One that does the cmpxchg change
and one that changes PPC_ATOMIC_ENTRY_BARRIER.
OK, make sense ;-)
quoted
Also given how pervasive this change is I'd like to take it via the powerpc
next tree, so can you please send this patch (which will be two after you split
it) as powerpc patches. And the rest can go via tip?
One problem is that patch 5 will remove __xchg_u32 and __xchg_64
entirely, which are modified in this patch(patch 1), so there will be
some conflicts if two branch get merged, I think.
Alternative way is that all this series go to powerpc next tree as most
of the dependent patches are already there. I just need to remove
inc/dec related code and resend them when appropriate. Besides, I can
pull patch 2 out and send it as a tip patch because it's general code
and no one depends on this in this series.
To summerize:
patch 1(split to two), 3, 4(remove inc/dec implementation), 5, 6 sent as
powerpc patches for powerpc next, patch 2(unmodified) sent as tip patch
for locking/core.
Peter and Michael, this works for you both?
On Fri, Oct 30, 2015 at 08:56:33AM +0800, Boqun Feng wrote:
On Tue, Oct 27, 2015 at 11:06:52AM +0800, Boqun Feng wrote:
quoted
On Tue, Oct 27, 2015 at 01:33:47PM +1100, Michael Ellerman wrote:
quoted
On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote:
quoted
This patch fixes two problems to make value-returning atomics and
{cmp}xchg fully ordered on PPC.
Hi Boqun,
Can you please split this into two patches. One that does the cmpxchg change
and one that changes PPC_ATOMIC_ENTRY_BARRIER.
OK, make sense ;-)
quoted
Also given how pervasive this change is I'd like to take it via the powerpc
next tree, so can you please send this patch (which will be two after you split
it) as powerpc patches. And the rest can go via tip?
One problem is that patch 5 will remove __xchg_u32 and __xchg_64
entirely, which are modified in this patch(patch 1), so there will be
some conflicts if two branch get merged, I think.
Alternative way is that all this series go to powerpc next tree as most
of the dependent patches are already there. I just need to remove
inc/dec related code and resend them when appropriate. Besides, I can
pull patch 2 out and send it as a tip patch because it's general code
and no one depends on this in this series.
To summerize:
patch 1(split to two), 3, 4(remove inc/dec implementation), 5, 6 sent as
powerpc patches for powerpc next, patch 2(unmodified) sent as tip patch
for locking/core.
Peter and Michael, this works for you both?
Thoughts? ;-)
Peter and Michael, I will split patch 1 to two and send them as patches
for powerpc next first. The rest of this can wait util we are on the
same page of where they'd better go.
Regards,
Boqun
On Mon, Nov 02, 2015 at 09:22:40AM +0800, Boqun Feng wrote:
quoted
On Tue, Oct 27, 2015 at 11:06:52AM +0800, Boqun Feng wrote:
quoted
To summerize:
patch 1(split to two), 3, 4(remove inc/dec implementation), 5, 6 sent as
powerpc patches for powerpc next, patch 2(unmodified) sent as tip patch
for locking/core.
Peter and Michael, this works for you both?
Thoughts? ;-)
Peter and Michael, I will split patch 1 to two and send them as patches
for powerpc next first. The rest of this can wait util we are on the
same page of where they'd better go.
I'm about to send patch 2(adding trivial tests) as a patch for the tip
tree, and rest of this series will be patches for powerpc next.
Will, AFAIK, you are currently working on variants on arm64, right? I
wonder whether you depend on patch 3 (allow archictures to provide
self-defined __atomic_op_*), if so I can also send patch 3 as a patch
for tip tree and wait until it merged into powerpc next to send the
rest.
Thanks and Best Regards,
Boqun
From: Will Deacon <hidden> Date: 2015-11-04 10:15:22
On Wed, Nov 04, 2015 at 09:22:13AM +0800, Boqun Feng wrote:
Will, AFAIK, you are currently working on variants on arm64, right? I
wonder whether you depend on patch 3 (allow archictures to provide
self-defined __atomic_op_*), if so I can also send patch 3 as a patch
for tip tree and wait until it merged into powerpc next to send the
rest.
The arm64 patches are all queued in the arm64 tree and have been sitting
in -next for a while. They don't dependent on anything else.
Will