Displaying 20 results from an estimated 5000 matches similar to: "[PATCH] virtio_ring: Update weak barriers to use dma_wmb/rmb"
2015 Apr 08
0
[PATCH] virtio_ring: Update weak barriers to use dma_wmb/rmb
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.
>
> The advantage to this is that these barriers are available to uniprocessor
2015 Apr 08
2
[PATCH] virtio_ring: Update weak barriers to use dma_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.
>>
>>
2015 Apr 08
2
[PATCH] virtio_ring: Update weak barriers to use dma_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.
>>
>>
2018 Apr 19
4
[PATCH] virtio_ring: switch to dma_XX barriers for rpmsg
virtio is using barriers to order memory accesses, thus
dma_wmb/rmb is a good match.
Build-tested on x86: Before
[mst at tuck linux]$ size drivers/virtio/virtio_ring.o
text data bss dec hex filename
11392 820 0 12212 2fb4 drivers/virtio/virtio_ring.o
After
mst at tuck linux]$ size drivers/virtio/virtio_ring.o
text data bss dec hex filename
2018 Apr 19
4
[PATCH] virtio_ring: switch to dma_XX barriers for rpmsg
virtio is using barriers to order memory accesses, thus
dma_wmb/rmb is a good match.
Build-tested on x86: Before
[mst at tuck linux]$ size drivers/virtio/virtio_ring.o
text data bss dec hex filename
11392 820 0 12212 2fb4 drivers/virtio/virtio_ring.o
After
mst at tuck linux]$ size drivers/virtio/virtio_ring.o
text data bss dec hex filename
2015 Dec 31
54
[PATCH v2 00/34] arch: barrier cleanup + barriers for virt
Changes since v1:
- replaced my asm-generic patch with an equivalent patch already in tip
- add wrappers with virt_ prefix for better code annotation,
as suggested by David Miller
- dropped XXX in patch names as this makes vger choke, Cc all relevant
mailing lists on all patches (not personal email, as the list becomes
too long then)
I parked this in vhost tree for now, but the
2015 Dec 31
54
[PATCH v2 00/34] arch: barrier cleanup + barriers for virt
Changes since v1:
- replaced my asm-generic patch with an equivalent patch already in tip
- add wrappers with virt_ prefix for better code annotation,
as suggested by David Miller
- dropped XXX in patch names as this makes vger choke, Cc all relevant
mailing lists on all patches (not personal email, as the list becomes
too long then)
I parked this in vhost tree for now, but the
2015 Apr 08
0
[PATCH] virtio_ring: Update weak barriers to use dma_wmb/rmb
On Wed, Apr 08, 2015 at 07:41:49AM -0700, Alexander Duyck wrote:
>
> 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
2015 Dec 30
46
[PATCH 00/34] arch: barrier cleanup + __smp_XXX barriers for virt
This is really trying to cleanup some virt code, as suggested by Peter, who
said
> You could of course go fix that instead of mutilating things into
> sort-of functional state.
This work is needed for virtio, so it's probably easiest to
merge it through my tree - is this fine by everyone?
Arnd, if you agree, could you ack this please?
Note to arch maintainers: please don't
2015 Dec 30
46
[PATCH 00/34] arch: barrier cleanup + __smp_XXX barriers for virt
This is really trying to cleanup some virt code, as suggested by Peter, who
said
> You could of course go fix that instead of mutilating things into
> sort-of functional state.
This work is needed for virtio, so it's probably easiest to
merge it through my tree - is this fine by everyone?
Arnd, if you agree, could you ack this please?
Note to arch maintainers: please don't
2015 Dec 17
2
[PATCH] virtio_ring: use smp_store_mb
On Thu, Dec 17, 2015 at 12:22:22PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote:
> > Seems to give a speedup on my box but I'm less sure about this one. E.g. as
> > xchng faster than mfence on all/most intel CPUs? Anyone has an opinion?
>
> Would help if you Cc people who would actually know this :-)
Good point. Glad
2015 Dec 17
2
[PATCH] virtio_ring: use smp_store_mb
On Thu, Dec 17, 2015 at 12:22:22PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote:
> > Seems to give a speedup on my box but I'm less sure about this one. E.g. as
> > xchng faster than mfence on all/most intel CPUs? Anyone has an opinion?
>
> Would help if you Cc people who would actually know this :-)
Good point. Glad
2016 Jan 10
48
[PATCH v3 00/41] arch: barrier cleanup + barriers for virt
Changes since v2:
- extended checkpatch tests for barriers, and added patches
teaching it to warn about incorrect usage of barriers
(__smp_xxx barriers are for use by asm-generic code only),
should help prevent misuse by arch code
to address comments by Russell King
- patched more instances of xen to use virt_ barriers
as suggested by Stefano Stabellini
- implemented a 2 byte xchg on sh
2016 Jan 10
48
[PATCH v3 00/41] arch: barrier cleanup + barriers for virt
Changes since v2:
- extended checkpatch tests for barriers, and added patches
teaching it to warn about incorrect usage of barriers
(__smp_xxx barriers are for use by asm-generic code only),
should help prevent misuse by arch code
to address comments by Russell King
- patched more instances of xen to use virt_ barriers
as suggested by Stefano Stabellini
- implemented a 2 byte xchg on sh
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
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
2015 Dec 17
2
[PATCH] virtio_ring: use smp_store_mb
On Thu, Dec 17, 2015 at 11:52:38AM +0100, Peter Zijlstra wrote:
> On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote:
> > +static inline void virtio_store_mb(bool weak_barriers,
> > + __virtio16 *p, __virtio16 v)
> > +{
> > +#ifdef CONFIG_SMP
> > + if (weak_barriers)
> > + smp_store_mb(*p, v);
> > + else
> > +#endif
>
2015 Dec 17
2
[PATCH] virtio_ring: use smp_store_mb
On Thu, Dec 17, 2015 at 11:52:38AM +0100, Peter Zijlstra wrote:
> On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote:
> > +static inline void virtio_store_mb(bool weak_barriers,
> > + __virtio16 *p, __virtio16 v)
> > +{
> > +#ifdef CONFIG_SMP
> > + if (weak_barriers)
> > + smp_store_mb(*p, v);
> > + else
> > +#endif
>
2015 Dec 17
4
[PATCH] virtio_ring: use smp_store_mb
We need a full barrier after writing out event index, using smp_store_mb
there seems better than open-coding.
As usual, we need a wrapper to account for strong barriers/non smp.
It's tempting to use this in vhost as well, for that, we'll
need a variant of smp_store_mb that works on __user pointers.
Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
---
Seems to give a speedup
2015 Dec 17
4
[PATCH] virtio_ring: use smp_store_mb
We need a full barrier after writing out event index, using smp_store_mb
there seems better than open-coding.
As usual, we need a wrapper to account for strong barriers/non smp.
It's tempting to use this in vhost as well, for that, we'll
need a variant of smp_store_mb that works on __user pointers.
Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
---
Seems to give a speedup