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

[Paolo Bonzini <pbonzini@redhat.com>]

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.

Paolo