On 01/11/2010 09:19 AM, Avi Kivity wrote:
OTOH, if we aggressively poll the ring when we have an opportunity
to, there's very little down side to that and it addresses the
serialization problem.
But we can't guarantee that we'll get those opportunities, so it
doesn't address the problem in a general way. A guest that doesn't
use hpet and only has a single virtio-blk device will not have any
reason to exit to qemu.
We can mitigate this with a timer but honestly, we need to do perf
measurements to see. My feeling is that we will need some more
aggressive form of polling than just waiting for IO completion. I
don't think queue depth is enough because it assumes that all
requests are equal. When dealing with cache=off or even just storage
with it's own cache, that's simply not the case.
Maybe we can adapt behaviour dynamically based on how fast results
come in.
Based on our experiences with virtio-net, what I'd suggest is to make a
lot of tunable options (ring size, various tx mitigation schemes,
timeout durations, etc) and then we can do some deep performance studies
to see how things interact with each other.
I think we should do that before making any changes because I'm deeply
concerned that we'll introduce significant performance regressions.
Regards,
Anthony Liguori