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

[Anthony Liguori]

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