On Mon, Oct 26, 2015 at 8:32 PM, Paolo Bonzini <pbonz...@redhat.com> 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.
