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,...