search for: smp_load_acquire

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...+#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_...

...+#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_...

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

...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)????????????????????????????????????????????...

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