Thread (5 messages) 5 messages, 2 authors, 2010-01-27

Re: [PATCH] virtio: use smp_XX barriers

flat view

From: "Michael S. Tsirkin" <mst@redhat.com>
Date: 2010-01-27 09:36:10

On Wed, Jan 27, 2010 at 11:28:32AM +0200, Avi Kivity wrote:
On 01/21/2010 07:10 PM, Michael S. Tsirkin wrote:
quoted
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.

   
This is wrong.  A UP guest still runs in parallel with the virtio device.
Yes, you are right here. I forgot that these macros
are compiled out on UP guest. Rusty please ignore this patch.
smp_mb() is used for processor-vs-processor ordering, which can't happen  
on UP systems, but for process-vs-device, we must use mb().

(this shows up if running a UP guest on an SMP host).
Currently, yes. But virtio is not a real device.
Here's what I was really trying to improve: rmb() is an lfence on
x86_64, but smp_rmb() is a barrier() and this is really sufficient for
virtio because x86_64 does not reorder memory reads.

Does this mean such an optimization would need a new macro?

-- 
MST
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help