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
