All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [PATCH] virtio_ring: Update weak barriers to use dma_wmb/rmb
Date: Wed, 08 Apr 2015 07:41:49 -0700	[thread overview]
Message-ID: <55253E2D.5020704@redhat.com> (raw)
In-Reply-To: <20150408093032-mutt-send-email-mst@redhat.com>


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.
>>
>> 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: Alexander Duyck <alexander.h.duyck@redhat.com>
> Well the generic implementation has:
> #ifndef dma_rmb
> #define dma_rmb()       rmb()
> #endif
>
> #ifndef dma_wmb
> #define dma_wmb()       wmb()
> #endif
>
> So for these arches you are slightly speeding up UP but slightly hurting SMP -
> I think we did benchmark the difference as measureable in the past.

The generic implementation for the smp_ barriers does the same thing 
when CONFIG_SMP is defined.  The only spot where there should be an 
appreciable difference between the two is on ARM where we define the 
dma_ barriers as being in the outer shareable domain, and for the smp_ 
barriers they are inner shareable domain.

> Additionally, isn't this relying on undocumented behaviour?
> The documentation says:
> 	"These are for use with consistent memory"
> and virtio does not bother to request consistent memory
> allocations.

Consistent in this case represents memory that exists within one 
coherency domain.  So in the case of x86 for instance this represents 
writes only to system memory.  If you mix writes to system memory and 
device memory (PIO) then you should be using the full wmb/rmb to 
guarantee ordering between the two memories.

> One wonders whether these will always be strong enough.

For the purposes of weak barriers they should be, and they are only 
slightly stronger than SMP in one case so odds are strength will not be 
the issue.  As far as speed I would suspect that the difference between 
inner and outer shareable domain should be negligible compared to the 
difference between a dsb() and a dmb().

- Alex

WARNING: multiple messages have this Message-ID (diff)
From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, rusty@rustcorp.com.au
Subject: Re: [PATCH] virtio_ring: Update weak barriers to use dma_wmb/rmb
Date: Wed, 08 Apr 2015 07:41:49 -0700	[thread overview]
Message-ID: <55253E2D.5020704@redhat.com> (raw)
In-Reply-To: <20150408093032-mutt-send-email-mst@redhat.com>


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.
>>
>> 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: Alexander Duyck <alexander.h.duyck@redhat.com>
> Well the generic implementation has:
> #ifndef dma_rmb
> #define dma_rmb()       rmb()
> #endif
>
> #ifndef dma_wmb
> #define dma_wmb()       wmb()
> #endif
>
> So for these arches you are slightly speeding up UP but slightly hurting SMP -
> I think we did benchmark the difference as measureable in the past.

The generic implementation for the smp_ barriers does the same thing 
when CONFIG_SMP is defined.  The only spot where there should be an 
appreciable difference between the two is on ARM where we define the 
dma_ barriers as being in the outer shareable domain, and for the smp_ 
barriers they are inner shareable domain.

> Additionally, isn't this relying on undocumented behaviour?
> The documentation says:
> 	"These are for use with consistent memory"
> and virtio does not bother to request consistent memory
> allocations.

Consistent in this case represents memory that exists within one 
coherency domain.  So in the case of x86 for instance this represents 
writes only to system memory.  If you mix writes to system memory and 
device memory (PIO) then you should be using the full wmb/rmb to 
guarantee ordering between the two memories.

> One wonders whether these will always be strong enough.

For the purposes of weak barriers they should be, and they are only 
slightly stronger than SMP in one case so odds are strength will not be 
the issue.  As far as speed I would suspect that the difference between 
inner and outer shareable domain should be negligible compared to the 
difference between a dsb() and a dmb().

- Alex

  reply	other threads:[~2015-04-08 14:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-08  0:47 [PATCH] virtio_ring: Update weak barriers to use dma_wmb/rmb Alexander Duyck
2015-04-08  8:42 ` Michael S. Tsirkin
2015-04-08  8:42   ` Michael S. Tsirkin
2015-04-08 14:41   ` Alexander Duyck [this message]
2015-04-08 14:41     ` Alexander Duyck
2015-04-08 18:37     ` Michael S. Tsirkin
2015-04-08 18:37       ` Michael S. Tsirkin
2015-04-08 20:31       ` Alexander Duyck
2015-04-08 20:31       ` Alexander Duyck
2015-04-10  3:17 ` Rusty Russell
2015-04-10  3:17 ` Rusty Russell
  -- strict thread matches above, loose matches on Subject: below --
2015-04-08  0:47 Alexander Duyck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55253E2D.5020704@redhat.com \
    --to=alexander.h.duyck@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.