similar to: read_barrier_depends() usage in vhost.c

On Thu, Oct 17, 2019 at 10:17:18AM +0800, Jason Wang wrote: > On 2019/10/17 ??7:33, Will Deacon wrote: > > In an attempt to remove the remaining traces of [smp_]read_barrier_depends() > > following my previous patches to strengthen READ_ONCE() for Alpha [1], I > > ended up trying to decipher the read_barrier_depends() usage in the vhost > > driver: > > > >

On Thu, Oct 17, 2019 at 10:17:18AM +0800, Jason Wang wrote: > On 2019/10/17 ??7:33, Will Deacon wrote: > > In an attempt to remove the remaining traces of [smp_]read_barrier_depends() > > following my previous patches to strengthen READ_ONCE() for Alpha [1], I > > ended up trying to decipher the read_barrier_depends() usage in the vhost > > driver: > > > >

Will Deacon <will at kernel.org> wrote: > >> --->8 >> >> // drivers/vhost/vhost.c >> static int get_indirect(struct vhost_virtqueue *vq, >> struct iovec iov[], unsigned int iov_size, >> unsigned int *out_num, unsigned int *in_num, >> struct vhost_log *log, unsigned int *log_num,

On 2019/10/19 ??4:58, Will Deacon wrote: > On Thu, Oct 17, 2019 at 10:17:18AM +0800, Jason Wang wrote: >> On 2019/10/17 ??7:33, Will Deacon wrote: >>> In an attempt to remove the remaining traces of [smp_]read_barrier_depends() >>> following my previous patches to strengthen READ_ONCE() for Alpha [1], I >>> ended up trying to decipher the read_barrier_depends()

On 2019/10/17 ??7:33, Will Deacon wrote: > Hi all, > > In an attempt to remove the remaining traces of [smp_]read_barrier_depends() > following my previous patches to strengthen READ_ONCE() for Alpha [1], I > ended up trying to decipher the read_barrier_depends() usage in the vhost > driver: > > --->8 > > // drivers/vhost/vhost.c > static int get_indirect(struct

[Bah: I typoed the LKML address, so I've fixed it for this one] On Thu, Oct 17, 2019 at 12:33:40AM +0100, Will Deacon wrote: > Hi all, > > In an attempt to remove the remaining traces of [smp_]read_barrier_depends() > following my previous patches to strengthen READ_ONCE() for Alpha [1], I > ended up trying to decipher the read_barrier_depends() usage in the vhost > driver:

Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vhost/vhost.c | 93 +++++++++++++++++++++++++++++++-------------------- 1 file changed, 56 insertions(+), 37 deletions(-) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index c90f437..4d379ed 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -33,8 +33,8 @@ enum { VHOST_MEMORY_F_LOG = 0x1, };

Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vhost/vhost.c | 93 +++++++++++++++++++++++++++++++-------------------- 1 file changed, 56 insertions(+), 37 deletions(-) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index c90f437..4d379ed 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -33,8 +33,8 @@ enum { VHOST_MEMORY_F_LOG = 0x1, };

Hi all, Although [smp_]read_barrier_depends() became part of READ_ONCE() in commit 76ebbe78f739 ("locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()"), it still limps on in the Linux memory model with the sinister hope of attracting innocent new users so that it becomes impossible to remove altogether. Let's strike before it's too late: there's only

On 2020/6/8 ??8:52, Michael S. Tsirkin wrote: > As testing shows no performance change, switch to that now. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > Signed-off-by: Eugenio P?rez <eperezma at redhat.com> > Link: https://lore.kernel.org/r/20200401183118.8334-3-eperezma at redhat.com > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> >

On 2020/6/8 ??8:52, Michael S. Tsirkin wrote: > As testing shows no performance change, switch to that now. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > Signed-off-by: Eugenio P?rez <eperezma at redhat.com> > Link: https://lore.kernel.org/r/20200401183118.8334-3-eperezma at redhat.com > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> >

Because READ_ONCE() now implies read_barrier_depends(), the read_barrier_depends() in next_desc() is now redundant. This commit therefore removes it and the related comments. Signed-off-by: Paul E. McKenney <paulmck at linux.vnet.ibm.com> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: Jason Wang <jasowang at redhat.com> Cc: <kvm at vger.kernel.org> Cc:

Because READ_ONCE() now implies read_barrier_depends(), the read_barrier_depends() in next_desc() is now redundant. This commit therefore removes it and the related comments. Signed-off-by: Paul E. McKenney <paulmck at linux.vnet.ibm.com> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: Jason Wang <jasowang at redhat.com> Cc: <kvm at vger.kernel.org> Cc:

Hi all, This is version three of the patches I previously posted here: v1: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ v2: https://lore.kernel.org/r/20200630173734.14057-1-will at kernel.org Changes since v2 include: * Actually add the barrier in READ_ONCE() for Alpha! * Implement Alpha's smp_load_acquire() using __READ_ONCE(), rather than the other

Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vhost/vhost.c | 93 +++++++++++++++++++++++++++++++-------------------- 1 file changed, 56 insertions(+), 37 deletions(-) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index c90f437..4d379ed 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -33,8 +33,8 @@ enum { VHOST_MEMORY_F_LOG = 0x1, };

Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vhost/vhost.c | 93 +++++++++++++++++++++++++++++++-------------------- 1 file changed, 56 insertions(+), 37 deletions(-) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index c90f437..4d379ed 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -33,8 +33,8 @@ enum { VHOST_MEMORY_F_LOG = 0x1, };

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

This adds infrastructure required for supporting multiple ring formats. The idea is as follows: we convert descriptors to an independent format first, and process that converting to iov later. Used ring is similar: we fetch into an independent struct first, convert that to IOV later. The point is that we have a tight loop that fetches descriptors, which is good for cache utilization. This will

Hi all: This RFC implement packed ring layout. The code were tested with Tiwei's RFC V2 a thttps://lkml.org/lkml/2018/4/1/48. Some fixups and tweaks were needed on top of Tiwei's code to make it run. TCP stream and pktgen does not show obvious difference compared with split ring. Changes from V2: - do not use & in checking desc_event_flags - off should be most significant bit -