Displaying 20 results from an estimated 191 matches for "smp_load_acquir".
Did you mean:
smp_load_acquire
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...
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...
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
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
2015 Dec 17
0
[PATCH] virtio: use smp_load_acquire/smp_store_release
On Thu, Dec 17, 2015 at 12:29:03PM +0200, Michael S. Tsirkin wrote:
> +static inline __virtio16 virtio_load_acquire(bool weak_barriers, __virtio16 *p)
> +{
> + if (!weak_barriers) {
> + rmb();
> + return READ_ONCE(*p);
> + }
> +#ifdef CONFIG_SMP
> + return smp_load_acquire(p);
> +#else
> + dma_rmb();
> + return READ_ONCE(*p);
> +#endif
> +}
This too is wrong. Look for example at arm.
dma_rmb() is dmb(osh), while the smp_mb() used by smp_load_acquire() is
dmb(ish). They order completely different types of memory accesses.
Also, load_acquire() is fir...
2016 Jan 25
2
[v3,11/41] mips: reuse asm-generic/barrier.h
...---------
>
> commit 2cb4e83a1b5c89c8e39b8a64bd89269d05913e41
> Author: Paul E. McKenney <paulmck at linux.vnet.ibm.com>
> Date: Fri Jan 15 09:30:42 2016 -0800
>
> documentation: Distinguish between local and global transitivity
>
> The introduction of smp_load_acquire() and smp_store_release() had
> the side effect of introducing a weaker notion of transitivity:
> The transitivity of full smp_mb() barriers is global, but that
> of smp_store_release()/smp_load_acquire() chains is local. This
> commit therefore introduces the notion o...
2016 Jan 25
2
[v3,11/41] mips: reuse asm-generic/barrier.h
...---------
>
> commit 2cb4e83a1b5c89c8e39b8a64bd89269d05913e41
> Author: Paul E. McKenney <paulmck at linux.vnet.ibm.com>
> Date: Fri Jan 15 09:30:42 2016 -0800
>
> documentation: Distinguish between local and global transitivity
>
> The introduction of smp_load_acquire() and smp_store_release() had
> the side effect of introducing a weaker notion of transitivity:
> The transitivity of full smp_mb() barriers is global, but that
> of smp_store_release()/smp_load_acquire() chains is local. This
> commit therefore introduces the notion o...
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 and smp_load_acquir...
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 and smp_load_acquir...
2016 Jan 15
0
[v3,11/41] mips: reuse asm-generic/barrier.h
...-------------------------------------------------
commit 2cb4e83a1b5c89c8e39b8a64bd89269d05913e41
Author: Paul E. McKenney <paulmck at linux.vnet.ibm.com>
Date: Fri Jan 15 09:30:42 2016 -0800
documentation: Distinguish between local and global transitivity
The introduction of smp_load_acquire() and smp_store_release() had
the side effect of introducing a weaker notion of transitivity:
The transitivity of full smp_mb() barriers is global, but that
of smp_store_release()/smp_load_acquire() chains is local. This
commit therefore introduces the notion of local transitivity...
2016 Jan 26
0
[v3,11/41] mips: reuse asm-generic/barrier.h
...b4e83a1b5c89c8e39b8a64bd89269d05913e41
> > Author: Paul E. McKenney <paulmck at linux.vnet.ibm.com>
> > Date: Fri Jan 15 09:30:42 2016 -0800
> >
> > documentation: Distinguish between local and global transitivity
> >
> > The introduction of smp_load_acquire() and smp_store_release() had
> > the side effect of introducing a weaker notion of transitivity:
> > The transitivity of full smp_mb() barriers is global, but that
> > of smp_store_release()/smp_load_acquire() chains is local. This
> > commit therefore int...
2016 Jan 15
1
[v3,11/41] mips: reuse asm-generic/barrier.h
...ile'?
>
> commit 2cb4e83a1b5c89c8e39b8a64bd89269d05913e41
> Author: Paul E. McKenney <paulmck at linux.vnet.ibm.com>
> Date: Fri Jan 15 09:30:42 2016 -0800
>
> documentation: Distinguish between local and global transitivity
>
> The introduction of smp_load_acquire() and smp_store_release() had
> the side effect of introducing a weaker notion of transitivity:
> The transitivity of full smp_mb() barriers is global, but that
> of smp_store_release()/smp_load_acquire() chains is local. This
> commit therefore introduces the notion o...
2016 Jan 15
1
[v3,11/41] mips: reuse asm-generic/barrier.h
...ile'?
>
> commit 2cb4e83a1b5c89c8e39b8a64bd89269d05913e41
> Author: Paul E. McKenney <paulmck at linux.vnet.ibm.com>
> Date: Fri Jan 15 09:30:42 2016 -0800
>
> documentation: Distinguish between local and global transitivity
>
> The introduction of smp_load_acquire() and smp_store_release() had
> the side effect of introducing a weaker notion of transitivity:
> The transitivity of full smp_mb() barriers is global, but that
> of smp_store_release()/smp_load_acquire() chains is local. This
> commit therefore introduces the notion o...
2016 Jan 05
2
[PATCH v2 15/32] powerpc: define __smp_xxx
...t __) will not.
>
> Please note I did test this: for ppc code before and after
> this patch generates exactly the same binary on SMP and UP.
>
Yes, you're right, sorry for my mistake...
>
> > Another thing is that smp_lwsync() may have a third user(other than
> > smp_load_acquire() and smp_store_release()):
> >
> > http://article.gmane.org/gmane.linux.ports.ppc.embedded/89877
> >
> > I'm OK to change my patch accordingly, but do we really want
> > smp_lwsync() get involved in this cleanup? If I understand you
> > correctly, this cl...
2016 Jan 05
2
[PATCH v2 15/32] powerpc: define __smp_xxx
...t __) will not.
>
> Please note I did test this: for ppc code before and after
> this patch generates exactly the same binary on SMP and UP.
>
Yes, you're right, sorry for my mistake...
>
> > Another thing is that smp_lwsync() may have a third user(other than
> > smp_load_acquire() and smp_store_release()):
> >
> > http://article.gmane.org/gmane.linux.ports.ppc.embedded/89877
> >
> > I'm OK to change my patch accordingly, but do we really want
> > smp_lwsync() get involved in this cleanup? If I understand you
> > correctly, this cl...
2016 Jan 05
2
[PATCH v2 15/32] powerpc: define __smp_xxx
...+#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 third user(other than
smp_load_acquire() and smp_store_release()):
http://article.gmane.org/gmane.linux.ports.ppc.embedded/89877
I'm OK to change my patch accordingly, but do we really want
smp_lwsync() get involved in this cleanup? If I understand you
correctly, this cleanup focuses on external API like smp_{r,w,}mb(),
while smp...
2016 Jan 05
2
[PATCH v2 15/32] powerpc: define __smp_xxx
...+#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 third user(other than
smp_load_acquire() and smp_store_release()):
http://article.gmane.org/gmane.linux.ports.ppc.embedded/89877
I'm OK to change my patch accordingly, but do we really want
smp_lwsync() get involved in this cleanup? If I understand you
correctly, this cleanup focuses on external API like smp_{r,w,}mb(),
while smp...
2016 Jan 10
3
[PATCH v2 1/3] checkpatch.pl: add missing memory barriers
...qr{
> + store_release|
> + load_acquire|
> + store_mb|
> + ($barriers)
> + }x;
If I use a variable called $smp_barriers, I'd expect
it to actually be the smp_barriers, not to have to
prefix it with smp_ before using it.
my $smp_barriers = qr{
smp_store_release|
smp_load_acquire|
smp_store_mb|
smp_read_barrier_depends
}x;
or
my $smp_barriers = qr{
smp_(?:store_release|load_acquire|store_mb|read_barrier_depends)
}x;
?
> + my $all_barriers = qr{
> + $barriers|
> + smp_($smp_barriers)
> + }x;
And this shouldn't have a capture group....
2019 Aug 08
3
[PATCH V4 7/9] vhost: do not use RCU to synchronize MMU notifier with worker
...in, not clear this could be faster than a spinlock when the
>> barriers are correct...
>
I've done some benchmark[1] on x86, and yes it looks even slower. It
looks to me the atomic stuffs is not necessary, so in order to compare
it better with spinlock. I tweak it a little bit through
smp_load_acquire()/store_releaes() + mb() like:
static struct vhost_map *vhost_vq_access_map_begin(struct
vhost_virtqueue
*vq,??????????????????????????????????????????????????????????????????????????
?????????????????????????????????????????????????? unsigned int
type)???????????????????????????????????????????...
2016 Jan 10
3
[PATCH v2 1/3] checkpatch.pl: add missing memory barriers
...qr{
> + store_release|
> + load_acquire|
> + store_mb|
> + ($barriers)
> + }x;
If I use a variable called $smp_barriers, I'd expect
it to actually be the smp_barriers, not to have to
prefix it with smp_ before using it.
my $smp_barriers = qr{
smp_store_release|
smp_load_acquire|
smp_store_mb|
smp_read_barrier_depends
}x;
or
my $smp_barriers = qr{
smp_(?:store_release|load_acquire|store_mb|read_barrier_depends)
}x;
?
> + my $all_barriers = qr{
> + $barriers|
> + smp_($smp_barriers)
> + }x;
And this shouldn't have a capture group....