search for: smp_store_release

Displaying 20 results from an estimated 238 matches for "smp_store_release".

2016 Jan 15
5
[v3,11/41] mips: reuse asm-generic/barrier.h
On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > So smp_mb() provides transitivity, as do pairs of smp_store_release() > and smp_read_acquire(), But they provide different grades of transitivity, which is where all the confusion lays. smp_mb() is strongly/globally transitive, all CPUs will agree on the order. Whereas the RCpc release+acquire is weakly so, only the two cpus involved in the handover will agr...
2016 Jan 15
5
[v3,11/41] mips: reuse asm-generic/barrier.h
On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > So smp_mb() provides transitivity, as do pairs of smp_store_release() > and smp_read_acquire(), But they provide different grades of transitivity, which is where all the confusion lays. smp_mb() is strongly/globally transitive, all CPUs will agree on the order. Whereas the RCpc release+acquire is weakly so, only the two cpus involved in the handover will agr...
2017 Dec 05
3
[PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()
...nything until > > > you realize there's a dependency barrier within READ_ONCE. > > > > > > Barrier pairing was a useful tool to check code validity, > > > maybe there are other, better tools now. > > > > There are quite a few people who say that smp_store_release() is > > easier for the tools to analyze than is smp_wmb(). My experience with > > smp_read_barrier_depends() and rcu_dereference() leads me to believe > > that they are correct. > > OK, but smp_store_release is still not paired with anything since we > rely on READ_ONC...
2017 Dec 05
3
[PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()
...nything until > > > you realize there's a dependency barrier within READ_ONCE. > > > > > > Barrier pairing was a useful tool to check code validity, > > > maybe there are other, better tools now. > > > > There are quite a few people who say that smp_store_release() is > > easier for the tools to analyze than is smp_wmb(). My experience with > > smp_read_barrier_depends() and rcu_dereference() leads me to believe > > that they are correct. > > OK, but smp_store_release is still not paired with anything since we > rely on READ_ONC...
2017 Dec 05
3
[PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()
...just not worth the pain of keeping this in > > the generic model. > > > > Right. What I am saying is that for writes you need > > WRITE_ONCE(obj->val, 1); > smp_wmb(); > WRITE_ONCE(*foo, obj); I believe Peter was instead suggesting: WRITE_ONCE(obj->val, 1); smp_store_release(foo, obj); > and this barrier is no longer paired with anything until > you realize there's a dependency barrier within READ_ONCE. > > Barrier pairing was a useful tool to check code validity, > maybe there are other, better tools now. There are quite a few people who say that...
2017 Dec 05
3
[PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()
...just not worth the pain of keeping this in > > the generic model. > > > > Right. What I am saying is that for writes you need > > WRITE_ONCE(obj->val, 1); > smp_wmb(); > WRITE_ONCE(*foo, obj); I believe Peter was instead suggesting: WRITE_ONCE(obj->val, 1); smp_store_release(foo, obj); > and this barrier is no longer paired with anything until > you realize there's a dependency barrier within READ_ONCE. > > Barrier pairing was a useful tool to check code validity, > maybe there are other, better tools now. There are quite a few people who say that...
2017 Dec 05
3
[PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()
...;s a dependency barrier within READ_ONCE. > > > > > > > > > > Barrier pairing was a useful tool to check code validity, > > > > > maybe there are other, better tools now. > > > > > > > > There are quite a few people who say that smp_store_release() is > > > > easier for the tools to analyze than is smp_wmb(). My experience with > > > > smp_read_barrier_depends() and rcu_dereference() leads me to believe > > > > that they are correct. > > > > > > OK, but smp_store_release is still not p...
2017 Dec 05
3
[PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()
...;s a dependency barrier within READ_ONCE. > > > > > > > > > > Barrier pairing was a useful tool to check code validity, > > > > > maybe there are other, better tools now. > > > > > > > > There are quite a few people who say that smp_store_release() is > > > > easier for the tools to analyze than is smp_wmb(). My experience with > > > > smp_read_barrier_depends() and rcu_dereference() leads me to believe > > > > that they are correct. > > > > > > OK, but smp_store_release is still not p...
2016 Jan 25
2
[v3,11/41] mips: reuse asm-generic/barrier.h
Hi Paul, On Fri, Jan 15, 2016 at 09:39:12AM -0800, Paul E. McKenney wrote: > On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote: > > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > > > So smp_mb() provides transitivity, as do pairs of smp_store_release() > > > and smp_read_acquire(), > > > > But they provide different grades of transitivity, which is where all > > the confusion lays. > > > > smp_mb() is strongly/globally transitive, all CPUs will agree on the order. > > > > Whereas the RCpc r...
2016 Jan 25
2
[v3,11/41] mips: reuse asm-generic/barrier.h
Hi Paul, On Fri, Jan 15, 2016 at 09:39:12AM -0800, Paul E. McKenney wrote: > On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote: > > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > > > So smp_mb() provides transitivity, as do pairs of smp_store_release() > > > and smp_read_acquire(), > > > > But they provide different grades of transitivity, which is where all > > the confusion lays. > > > > smp_mb() is strongly/globally transitive, all CPUs will agree on the order. > > > > Whereas the RCpc r...
2016 Jan 12
4
[v3,11/41] mips: reuse asm-generic/barrier.h
On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: > On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, > smp_read_barrier_depends, smp_store_release and smp_load_acquire match > the asm-generic variants exactly. Drop the local definitions and pull in > asm-generic/barrier.h instead. > This statement doesn't fit MIPS barriers variations. Moreover, there is a reason to extend that even more specific, at least for smp_store_release...
2016 Jan 12
4
[v3,11/41] mips: reuse asm-generic/barrier.h
On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: > On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, > smp_read_barrier_depends, smp_store_release and smp_load_acquire match > the asm-generic variants exactly. Drop the local definitions and pull in > asm-generic/barrier.h instead. > This statement doesn't fit MIPS barriers variations. Moreover, there is a reason to extend that even more specific, at least for smp_store_release...
2015 Dec 17
2
[PATCH] virtio: use smp_load_acquire/smp_store_release
virtio ring entries have exactly the acquire/release semantics: - reading used index acquires a ring entry from host - updating the available index releases it to host Thus when using weak barriers and building for SMP (as most people do), smp_load_acquire and smp_store_release will do exactly the right thing to synchronize with the host. In fact, QEMU already uses __atomic_thread_fence(__ATOMIC_ACQUIRE) and __atomic_thread_fence(__ATOMIC_RELEASE); Documentation/circular-buffers.txt suggests smp_load_acquire and smp_store_release for head and tail updates. Since we have...
2015 Dec 17
2
[PATCH] virtio: use smp_load_acquire/smp_store_release
virtio ring entries have exactly the acquire/release semantics: - reading used index acquires a ring entry from host - updating the available index releases it to host Thus when using weak barriers and building for SMP (as most people do), smp_load_acquire and smp_store_release will do exactly the right thing to synchronize with the host. In fact, QEMU already uses __atomic_thread_fence(__ATOMIC_ACQUIRE) and __atomic_thread_fence(__ATOMIC_RELEASE); Documentation/circular-buffers.txt suggests smp_load_acquire and smp_store_release for head and tail updates. Since we have...
2016 Jan 15
0
[v3,11/41] mips: reuse asm-generic/barrier.h
On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote: > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > > So smp_mb() provides transitivity, as do pairs of smp_store_release() > > and smp_read_acquire(), > > But they provide different grades of transitivity, which is where all > the confusion lays. > > smp_mb() is strongly/globally transitive, all CPUs will agree on the order. > > Whereas the RCpc release+acquire is weakly so, only the tw...
2016 Jan 05
2
[PATCH v2 15/32] powerpc: define __smp_xxx
...> * This is a barrier which prevents following instructions from being > > > @@ -67,18 +59,18 @@ > > > #define data_barrier(x) \ > > > asm volatile("twi 0,%0,0; isync" : : "r" (x) : "memory"); > > > > > > -#define smp_store_release(p, v) \ > > > +#define __smp_store_release(p, v) \ > > > do { \ > > > compiletime_assert_atomic_type(*p); \ > > > - smp_lwsync(); \ > > > + __smp_lwsync(); \ > > > > , therefore this will emit an lwsync no...
2016 Jan 05
2
[PATCH v2 15/32] powerpc: define __smp_xxx
...> * This is a barrier which prevents following instructions from being > > > @@ -67,18 +59,18 @@ > > > #define data_barrier(x) \ > > > asm volatile("twi 0,%0,0; isync" : : "r" (x) : "memory"); > > > > > > -#define smp_store_release(p, v) \ > > > +#define __smp_store_release(p, v) \ > > > do { \ > > > compiletime_assert_atomic_type(*p); \ > > > - smp_lwsync(); \ > > > + __smp_lwsync(); \ > > > > , therefore this will emit an lwsync no...
2016 Jan 05
2
[PATCH v2 15/32] powerpc: define __smp_xxx
...c(SMPWMB) : : :"memory") > > /* > * This is a barrier which prevents following instructions from being > @@ -67,18 +59,18 @@ > #define data_barrier(x) \ > asm volatile("twi 0,%0,0; isync" : : "r" (x) : "memory"); > > -#define smp_store_release(p, v) \ > +#define __smp_store_release(p, v) \ > do { \ > compiletime_assert_atomic_type(*p); \ > - smp_lwsync(); \ > + __smp_lwsync(); \ , therefore this will emit an lwsync no matter SMP or UP. Another thing is that smp_lwsync() may have a thir...
2016 Jan 05
2
[PATCH v2 15/32] powerpc: define __smp_xxx
...c(SMPWMB) : : :"memory") > > /* > * This is a barrier which prevents following instructions from being > @@ -67,18 +59,18 @@ > #define data_barrier(x) \ > asm volatile("twi 0,%0,0; isync" : : "r" (x) : "memory"); > > -#define smp_store_release(p, v) \ > +#define __smp_store_release(p, v) \ > do { \ > compiletime_assert_atomic_type(*p); \ > - smp_lwsync(); \ > + __smp_lwsync(); \ , therefore this will emit an lwsync no matter SMP or UP. Another thing is that smp_lwsync() may have a thir...
2016 Jan 10
0
[PATCH v3 01/41] lcoking/barriers, arch: Use smp barriers in smp_store_release()
...de/asm/barrier.h @@ -36,7 +36,7 @@ #define smp_mb__before_atomic() smp_mb() #define smp_mb__after_atomic() smp_mb() -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); } while (0) +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } while (0) #define smp_store_release(p, v) \ do { \ diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h index b42afad..0f45f93 100644 --- a/include/asm-generic/barrier.h +++ b/include/asm-generic/barrier.h @@ -93,7 +93,7 @@ #endif /* CONFIG_SMP */ #ifndef smp_store_mb -#define smp_store_mb(var,...