Re: [PATCH bpf-next 2/3] tools, perf: use smp_{rmb,mb} barriers instead of {rmb,mb}
flat view
From: Alexei Starovoitov <hidden>
Date: 2018-10-18 23:34:46
On Thu, Oct 18, 2018 at 05:04:34PM +0200, Daniel Borkmann wrote:
quoted hunk ↗ jump to hunk
#endif /* _TOOLS_LINUX_ASM_IA64_BARRIER_H */diff --git a/tools/arch/powerpc/include/asm/barrier.h b/tools/arch/powerpc/include/asm/barrier.h index a634da0..905a2c6 100644 --- a/tools/arch/powerpc/include/asm/barrier.h +++ b/tools/arch/powerpc/include/asm/barrier.h@@ -27,4 +27,20 @@ #define rmb() __asm__ __volatile__ ("sync" : : : "memory") #define wmb() __asm__ __volatile__ ("sync" : : : "memory") +#if defined(__powerpc64__) +#define smp_lwsync() __asm__ __volatile__ ("lwsync" : : : "memory") + +#define smp_store_release(p, v) \ +do { \ + smp_lwsync(); \ + WRITE_ONCE(*p, v); \ +} while (0) + +#define smp_load_acquire(p) \ +({ \ + typeof(*p) ___p1 = READ_ONCE(*p); \ + smp_lwsync(); \ + ___p1; \
I don't like this proliferation of asm. Why do we think that we can do better job than compiler? can we please use gcc builtins instead? https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html __atomic_load_n(ptr, __ATOMIC_ACQUIRE); __atomic_store_n(ptr, val, __ATOMIC_RELEASE); are done specifically for this use case if I'm not mistaken. I think it pays to learn what compiler provides.