Re: [Qemu-devel] 4k seq read splitting for virtio-blk - possible workarounds?

[Andrey Korolyov]

On Mon, Oct 26, 2015 at 8:32 PM, Paolo Bonzini <address@hidden> wrote:
>
>
> On 26/10/2015 18:18, Andrey Korolyov wrote:
>> Yes, both cases are positive, thanks for very detailed explanation and
>> for tips. Does this also mean that most current distros which are
>> using 'broken' >=3.13 <4.2 driver would bring sequential read
>> performance, especially on rotating media, or media with high request
>> latency like hybrid disk, down to knees for virtio, which almost
>> always is a default selection?
>
> Yes, this is why I said the conversion was premature.  On one hand I
> totally agree that virtio-blk is a great guinea pig for blk-mq
> conversion, on the other hand people are using the thing in production
> and the effects weren't quite understood.
>
> It's a common misconception that virt doesn't benefit from the elevator,
> but actually you get (well... used to get...) much better performance
> from the deadline scheduler than the noop scheduler.  Merging is the
> main reason, because it lowers the amount of work that you have to do in
> the host.
>
> Even if you don't get better performance, merging will get better CPU
> utilization because the longer s/g lists take time to process in the
> host, and the effect's much larger than a few extra milliwatts in a
> bare-metal controller.
>
> Having a "real" multiqueue model in the host (real = one I/O thread and
> one AIO context per guest queue, with each I/O thread able to service
> multiple disks; rather than a "fake" multiqueue where you still have one
> I/O thread and AIO context per guest disk, so all the queues really
> funnel into one in the host) should fix this, but it's at least a few
> months away in QEMU... probably something like QEMU 2.8.  My plan is for
> 2.6 to have fine-grained critical sections (patches written, will repost
> during 2.5 hard freeze), 2.7 (unlikely 2.6) to have fine-grained locks,
> and 2.8 or 2.9 to have multiqueue.
>


BTW it seems that I made a little stronger claim than it is actually -
at least 3.18 works fine in all cases, so the issue was fixed a bit
earlier than in 4.2. If this is true, fix could possibly land in
remaining distro queues, even if they are not following stable
branches. I could bisect this in a spare time because I don`t see any
obvious candidates from the diff which would fix a misbehavior at a
glance.