Thread (17 messages) 17 messages, 3 authors, 2011-12-02

Re: [RFC] virtio: use mandatory barriers for remote processor vdevs

From: Rusty Russell <hidden>
Date: 2011-12-02 01:11:03
Also in: kvm, linux-arm-kernel, lkml

Possibly related (same subject, not in this thread)

On Thu, 1 Dec 2011 10:12:37 +0200, "Michael S. Tsirkin" [off-list ref] wrote:
On Thu, Dec 01, 2011 at 12:58:59PM +1030, Rusty Russell wrote:
quoted
On Thu, 1 Dec 2011 01:13:07 +0200, "Michael S. Tsirkin" [off-list ref] wrote:
quoted
For x86, stores into memory are ordered. So I think that yes, smp_XXX
can be selected at compile time.

So let's forget the virtio strangeness for a minute,
Hmm, we got away with light barriers because we knew we were not
*really* talking to a device.  But now with virtio-mmio, turns out we
are :)
You think virtio-mmio this issue too?  It's reported on remoteproc...
I think any non-virtual, non-PCI device has to worry about it.  Perhaps
all virtio-mmio are virtual (at this point).

I'm tempted to say we want permission from the device to do relaxed
barriers (so I don't have to worry about it!)
quoted
I'm really tempted to revert d57ed95 for 3.2, and we can revisit this
optimization later if it proves worthwhile.
Generally it does seem the best we can do for 3.2.

Given it's rc3, I'd be a bit wary of introducing regressions - I'll try
to find some real setups (as in - not my laptop) to run some benchmarks
on, to verify there's no major problem.
I hope I can report on this in about a week from now - want to hold onto this meanwhile?
Yep, no huge hurry.  Thanks!

Cheers,
Rusty.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help