Re: [RFC] vhost-blk implementation

[Avi Kivity <avi@redhat.com>]

On 03/30/2010 01:51 AM, Badari Pulavarty wrote:
>
>    
>>> Your io wait time is twice as long and your throughput is about half.
>>> I think the qmeu block submission does an extra attempt at merging
>>> requests.  Does blktrace tell you anything interesting?
>>>
>>>        
> Yes. I see that in my testcase (2M writes) - QEMU is pickup 512K
> requests from the virtio ring and merging them back to 2M before
> submitting them.
>
> Unfortunately, I can't do that quite easily in vhost-blk. QEMU
> does re-creates iovecs for the merged IO. I have to come up with
> a scheme to do this :(
>    

I don't think that either vhost-blk or virtio-blk should do this.  
Merging increases latency, and in the case of streaming writes makes it 
impossible for the guest to prepare new requests while earlier ones are 
being serviced (in effect it reduces the queue depth to 1).

qcow2 does benefit from merging, but it should do so itself without 
impacting raw.

>> It does.  I suggest using fio O_DIRECT random access patterns to avoid
>> such issues.
>>      
> Well, I am not trying to come up with a test case where vhost-blk
> performs better than virtio-blk. I am trying to understand where
> and why vhost-blk performnce worse than virtio-blk.
>    

In this case qemu-virtio is making an incorrect tradeoff.  The guest 
could easily merge those requests itself.  If you want larger writes, 
tune the guest to issue them.

Another way to look at it:  merging improved bandwidth but increased 
latency, yet you are only measuring bandwidth.  If you measured only 
latency you'd find that vhost-blk is better.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.