Link for v1: https://lkml.org/lkml/2015/8/27/798
Changes since v1:
* avoid to introduce macro arch_atomic_op_*()
* also fix the problem that cmpxchg, xchg and their atomic_
versions are not full barriers in PPC implementation.
* rebase on v4.3-rc1
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"
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 powerpc, 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 full barriers in current PPC implementation, which is incorrect
according to memory-barriers.txt.
Therefore this patchset implements the relaxed/acquire/release variants
based on powerpc memory model and specific barriers, and fix cmpxchg,
xchg and their atomic_ versions. A trivial test for these new variants
is 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 7 parts:
1. Add trivial tests for the new variants in lib/atomic64_test.c
2. Allow architectures to define their own __atomic_op_*() helpers
to build other variants based on relaxed.
3. Implement atomic{,64}_{add,sub}_return_* variants
4. Implement xchg_* and atomic{,64}_xchg_* variants
5. Implement cmpxchg_* atomic{,64}_cmpxchg_* variants
6. Make atomic{,64}_xchg and xchg full barriers
7. Make atomic{,64}_cmpxchg and cmpxchg full barriers
This patchset is based on v4.3-rc1 and all patches are built and boot
tested for little endian powernv and pseries, and also tested by 0day.
Looking forward to any suggestion, question and comment ;-)
Regards,
Boqun
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
