On Mon, May 21, 2012 at 10:11:06AM +0200, Paolo Bonzini wrote: > Il 21/05/2012 03:56, Benjamin Herrenschmidt ha scritto: > > I don't see an obvious need to provide a "relaxed" variant of the > > later at this stage, a quick grep doesn't seem to show that most cases > > where it's used are either not performance sensitive or the barrier > > makes sense, but feel free to prove me wrong :-) > > The only problem here is that you have useless memory barriers when > calling cpu_physical_memory_map in a loop (see virtqueue_map_sg). > > Paolo
More than that. smp_mb is pretty expensive. You often can do just smp_wmb and smp_rmb and that is very cheap. Many operations run in the vcpu context or start when guest exits to host and work is bounced from there and thus no barrier is needed here. Example? start_xmit in e1000. Executed in vcpu context so no barrier is needed. virtio of course is another example since it does its own barriers. But even without that, virtio_blk_handle_output runs in vcpu context. But more importantly, this hack just sweeps the dirt under the carpet. Understanding the interaction with guest drivers is important anyway. So I really don't see why don't we audit devices and add proper barriers. -- MST
