aboutsummaryrefslogtreecommitdiffstats
path: root/arch/ia64
diff options
context:
space:
mode:
authorPeter Zijlstra <peterz@infradead.org>2013-11-06 08:57:36 -0500
committerIngo Molnar <mingo@kernel.org>2014-01-12 04:37:17 -0500
commit47933ad41a86a4a9b50bed7c9b9bd2ba242aac63 (patch)
tree4f1d94f4b09ecf0c1d99f295f2c31b22eebed492 /arch/ia64
parent93ea02bb84354370e51de803a9405f171f3edf88 (diff)
arch: Introduce smp_load_acquire(), smp_store_release()
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 cheaper ways to handle these situations, but the Linux kernel currently has no portable way to make use of them. This commit therefore supplies smp_load_acquire() and smp_store_release() to remedy this situation. The new smp_load_acquire() primitive orders the specified load against any subsequent reads or writes, while the new smp_store_release() primitive orders the specifed store against any prior reads or writes. These primitives allow array-based circular FIFOs to be implemented without an smp_mb(), and also allow a theoretical hole in rcu_assign_pointer() to be closed at no additional expense on most architectures. In addition, the RCU experience transitioning from explicit smp_read_barrier_depends() and smp_wmb() to rcu_dereference() and rcu_assign_pointer(), respectively resulted in substantial improvements in readability. It therefore seems likely that replacing other explicit barriers with smp_load_acquire() and smp_store_release() will provide similar benefits. It appears that roughly half of the explicit barriers in core kernel code might be so replaced. [Changelog by PaulMck] Reviewed-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Acked-by: Will Deacon <will.deacon@arm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Cc: Michael Ellerman <michael@ellerman.id.au> Cc: Michael Neuling <mikey@neuling.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Victor Kaplansky <VICTORK@il.ibm.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Oleg Nesterov <oleg@redhat.com> Link: http://lkml.kernel.org/r/20131213150640.908486364@infradead.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'arch/ia64')
-rw-r--r--arch/ia64/include/asm/barrier.h23
1 files changed, 23 insertions, 0 deletions
diff --git a/arch/ia64/include/asm/barrier.h b/arch/ia64/include/asm/barrier.h
index 60576e06b6fb..d0a69aa35e27 100644
--- a/arch/ia64/include/asm/barrier.h
+++ b/arch/ia64/include/asm/barrier.h
@@ -45,14 +45,37 @@
45# define smp_rmb() rmb() 45# define smp_rmb() rmb()
46# define smp_wmb() wmb() 46# define smp_wmb() wmb()
47# define smp_read_barrier_depends() read_barrier_depends() 47# define smp_read_barrier_depends() read_barrier_depends()
48
48#else 49#else
50
49# define smp_mb() barrier() 51# define smp_mb() barrier()
50# define smp_rmb() barrier() 52# define smp_rmb() barrier()
51# define smp_wmb() barrier() 53# define smp_wmb() barrier()
52# define smp_read_barrier_depends() do { } while(0) 54# define smp_read_barrier_depends() do { } while(0)
55
53#endif 56#endif
54 57
55/* 58/*
59 * IA64 GCC turns volatile stores into st.rel and volatile loads into ld.acq no
60 * need for asm trickery!
61 */
62
63#define smp_store_release(p, v) \
64do { \
65 compiletime_assert_atomic_type(*p); \
66 barrier(); \
67 ACCESS_ONCE(*p) = (v); \
68} while (0)
69
70#define smp_load_acquire(p) \
71({ \
72 typeof(*p) ___p1 = ACCESS_ONCE(*p); \
73 compiletime_assert_atomic_type(*p); \
74 barrier(); \
75 ___p1; \
76})
77
78/*
56 * XXX check on this ---I suspect what Linus really wants here is 79 * XXX check on this ---I suspect what Linus really wants here is
57 * acquire vs release semantics but we can't discuss this stuff with 80 * acquire vs release semantics but we can't discuss this stuff with
58 * Linus just yet. Grrr... 81 * Linus just yet. Grrr...