similar to: [PATCH] vhost-net: switch to smp barriers

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)

Documentation/memory-barriers.txt says: Mandatory barriers should not be used to control SMP effects, since mandatory barriers unnecessarily impose overhead on UP systems. This rule applies to virtio, so let's do it correctly. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_ring.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-)

Documentation/memory-barriers.txt says: Mandatory barriers should not be used to control SMP effects, since mandatory barriers unnecessarily impose overhead on UP systems. This rule applies to virtio, so let's do it correctly. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_ring.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-)

Virtio is using memory barriers to control the ordering of references to the vrings on SMP systems. When the guest is compiled with SMP support, virtio is only using SMP barriers in order to avoid incurring the overhead involved with mandatory barriers. Lately, though, virtio is being increasingly used with inter-processor communication scenarios too, which involve running two (separate)

Virtio is using memory barriers to control the ordering of references to the vrings on SMP systems. When the guest is compiled with SMP support, virtio is only using SMP barriers in order to avoid incurring the overhead involved with mandatory barriers. Lately, though, virtio is being increasingly used with inter-processor communication scenarios too, which involve running two (separate)

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

This change makes it so that instead of using smp_wmb/rmb which varies depending on the kernel configuration we can can use dma_wmb/rmb which for most architectures should be equal to or slightly more strict than smp_wmb/rmb. The advantage to this is that these barriers are available to uniprocessor builds as well so the performance should improve under such a configuration. Signed-off-by:

This change makes it so that instead of using smp_wmb/rmb which varies depending on the kernel configuration we can can use dma_wmb/rmb which for most architectures should be equal to or slightly more strict than smp_wmb/rmb. The advantage to this is that these barriers are available to uniprocessor builds as well so the performance should improve under such a configuration. Signed-off-by:

On 04/08/2015 01:42 AM, Michael S. Tsirkin wrote: > On Tue, Apr 07, 2015 at 05:47:42PM -0700, Alexander Duyck wrote: >> This change makes it so that instead of using smp_wmb/rmb which varies >> depending on the kernel configuration we can can use dma_wmb/rmb which for >> most architectures should be equal to or slightly more strict than >> smp_wmb/rmb. >> >>

On 04/08/2015 01:42 AM, Michael S. Tsirkin wrote: > On Tue, Apr 07, 2015 at 05:47:42PM -0700, Alexander Duyck wrote: >> This change makes it so that instead of using smp_wmb/rmb which varies >> depending on the kernel configuration we can can use dma_wmb/rmb which for >> most architectures should be equal to or slightly more strict than >> smp_wmb/rmb. >> >>

On Mon, 2016-01-04 at 22:45 +0200, Michael S. Tsirkin wrote: > 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:

On Mon, 2016-01-04 at 22:45 +0200, Michael S. Tsirkin wrote: > 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:

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 =~

As part of memory barrier cleanup, this patchset extends checkpatch to make it easier to stop incorrect memory barrier usage. This applies on top of my series arch: barrier cleanup + barriers for virt and will be included in the next version of the series. Michael S. Tsirkin (3): checkpatch.pl: add missing memory barriers checkpatch: check for __smp outside barrier.h checkpatch: add virt

As part of memory barrier cleanup, this patchset extends checkpatch to make it easier to stop incorrect memory barrier usage. This applies on top of my series arch: barrier cleanup + barriers for virt and will be included in the next version of the series. Michael S. Tsirkin (3): checkpatch.pl: add missing memory barriers checkpatch: check for __smp outside barrier.h checkpatch: add virt

As part of memory barrier cleanup, this patchset extends checkpatch to make it easier to stop incorrect memory barrier usage. This applies on top of my series arch: barrier cleanup + barriers for virt and will be included in the next version of the series. Changes from v2: catch optional\s* before () in barriers rewrite using qr{} instead of map Michael S. Tsirkin (3): checkpatch.pl: add

As part of memory barrier cleanup, this patchset extends checkpatch to make it easier to stop incorrect memory barrier usage. This applies on top of my series arch: barrier cleanup + barriers for virt and will be included in the next version of the series. Changes from v2: catch optional\s* before () in barriers rewrite using qr{} instead of map Michael S. Tsirkin (3): checkpatch.pl: add