Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device

[Anthony Liguori <anthony@codemonkey.ws>]

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