similar to: [PATCH RFC 0/4] barriers using data dependency

On Mon, Jan 07, 2019 at 11:58:23AM +0800, Jason Wang wrote: > > On 2019/1/3 ??4:57, Michael S. Tsirkin wrote: > > It's not uncommon to have two access two unrelated memory locations in a > > specific order. At the moment one has to use a memory barrier for this. > > > > However, if the first access was a read and the second used an address > > depending

It's not uncommon to have two access two unrelated memory locations in a specific order. At the moment one has to use a memory barrier for this. However, if the first access was a read and the second used an address depending on the first one we would have a data dependency and no barrier would be necessary. This adds a new interface: dependent_ptr_mb which does exactly this: it returns a

On 2019/1/3 ??4:57, Michael S. Tsirkin wrote: > It's not uncommon to have two access two unrelated memory locations in a > specific order. At the moment one has to use a memory barrier for this. > > However, if the first access was a read and the second used an address > depending on the first one we would have a data dependency and no > barrier would be necessary. > >

On 2019/1/3 ??4:57, Michael S. Tsirkin wrote: > It's not uncommon to have two access two unrelated memory locations in a > specific order. At the moment one has to use a memory barrier for this. > > However, if the first access was a read and the second used an address > depending on the first one we would have a data dependency and no > barrier would be necessary. > >

So as explained in Documentation/memory-barriers.txt e.g. a load followed by a store require a full memory barrier, to avoid store being ordered before the load. Similarly load-load requires a read memory barrier. Thinking about it, we can actually create a data dependency by mixing the first loaded value into the pointer being accessed. This adds an API for this and uses it in virtio. Written

virtio is communicating with a virtual "device" that actually runs on another host processor. Thus SMP barriers can be used to control memory access ordering. Where possible, we should use SMP barriers which are more lightweight than mandatory barriers, because mandatory barriers also control MMIO effects on accesses through relaxed memory I/O windows (which virtio does not use)

virtio is communicating with a virtual "device" that actually runs on another host processor. Thus SMP barriers can be used to control memory access ordering. Where possible, we should use SMP barriers which are more lightweight than mandatory barriers, because mandatory barriers also control MMIO effects on accesses through relaxed memory I/O windows (which virtio does not use)

On Mon, 2016-01-04 at 13:36 +0200, Michael S. Tsirkin wrote: > SMP-only barriers were missing in checkpatch.pl > > Refactor code slightly to make adding more variants easier. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > ?scripts/checkpatch.pl | 9 ++++++++- > ?1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git

On Mon, 2016-01-04 at 13:36 +0200, Michael S. Tsirkin wrote: > SMP-only barriers were missing in checkpatch.pl > > Refactor code slightly to make adding more variants easier. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > ?scripts/checkpatch.pl | 9 ++++++++- > ?1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git

Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/virtio/virtio_ring.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index 79e1b29..78428a8 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -35,7 +35,7 @@ #define virtio_rmb(vq) \ do { if

Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/virtio/virtio_ring.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index 79e1b29..78428a8 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -35,7 +35,7 @@ #define virtio_rmb(vq) \ do { if

We were cheating with our barriers; using the smp ones rather than the real device ones. That was fine, until virtio-mmio came along, which could be talking to a real device (a non-SMP CPU). Unfortunately, just putting back the real barriers (reverting d57ed95d) causes a performance regression on virtio-pci. In particular, Amos reports netbench's TCP_RR over virtio_net CPU utilization

We were cheating with our barriers; using the smp ones rather than the real device ones. That was fine, until virtio-mmio came along, which could be talking to a real device (a non-SMP CPU). Unfortunately, just putting back the real barriers (reverting d57ed95d) causes a performance regression on virtio-pci. In particular, Amos reports netbench's TCP_RR over virtio_net CPU utilization

On Sun, 2016-01-10 at 13:56 +0200, Michael S. Tsirkin wrote: > SMP-only barriers were missing in checkpatch.pl > > Refactor code slightly to make adding more variants easier. [] > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl [] > @@ -5116,7 +5116,25 @@ sub process { > ? } > ? } > ?# check for memory barriers without a comment. > - if ($line =~

On Sun, 2016-01-10 at 13:56 +0200, Michael S. Tsirkin wrote: > SMP-only barriers were missing in checkpatch.pl > > Refactor code slightly to make adding more variants easier. [] > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl [] > @@ -5116,7 +5116,25 @@ sub process { > ? } > ? } > ?# check for memory barriers without a comment. > - if ($line =~

Fix build after API changes. Reported-by: Kamal Mostafa <kamal at canonical.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- tools/virtio/asm/barrier.h | 22 +++++++++++++--------- tools/virtio/linux/compiler.h | 9 +++++++++ tools/virtio/linux/kernel.h | 1 + 3 files changed, 23 insertions(+), 9 deletions(-) create mode 100644 tools/virtio/linux/compiler.h

Fix build after API changes. Reported-by: Kamal Mostafa <kamal at canonical.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- tools/virtio/asm/barrier.h | 22 +++++++++++++--------- tools/virtio/linux/compiler.h | 9 +++++++++ tools/virtio/linux/kernel.h | 1 + 3 files changed, 23 insertions(+), 9 deletions(-) create mode 100644 tools/virtio/linux/compiler.h

On Mon, Jan 04, 2016 at 08:07:40AM -0800, Joe Perches wrote: > On Mon, 2016-01-04 at 13:36 +0200, Michael S. Tsirkin wrote: > > SMP-only barriers were missing in checkpatch.pl > > > > Refactor code slightly to make adding more variants easier. > > > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > > --- > > ?scripts/checkpatch.pl | 9

SMP-only barriers were missing in checkpatch.pl Refactor code slightly to make adding more variants easier. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- scripts/checkpatch.pl | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 2b3c228..0245bbe 100755 --- a/scripts/checkpatch.pl +++

SMP-only barriers were missing in checkpatch.pl Refactor code slightly to make adding more variants easier. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- scripts/checkpatch.pl | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 2b3c228..97b8b62 100755 --- a/scripts/checkpatch.pl +++