Linux's Multi-Queue Block Code Still Presenting Some Performance Regressions
For those thinking of switching to the new multi-queue block layer, a.k.a. blk-mq, be forewarned that there are still some regressions outstanding.
Long story short, if moving to the multi-queue block layer there are throughput and latency problems still outstanding, which can come up with any of the blk-mq I/O schedulers and many of the commonly used file-systems.
In severe cases noted by Mel Gorman, blk-mq can be about 38% slower while other less severe regressions are also possible depending upon your system configuration. The MQ problems are outlined in this mailing list post.
There is a new patch series authored by Red Hat developers to fix the MQ performance regression, but this few hundred lines of code hasn't been merged to the mainline kernel and might not end up happening until Linux 4.14.
At present, with the upcoming Linux 4.13 kernel the plan is to use the multi-queue block layer by default.
Long story short, if moving to the multi-queue block layer there are throughput and latency problems still outstanding, which can come up with any of the blk-mq I/O schedulers and many of the commonly used file-systems.
In severe cases noted by Mel Gorman, blk-mq can be about 38% slower while other less severe regressions are also possible depending upon your system configuration. The MQ problems are outlined in this mailing list post.
There is a new patch series authored by Red Hat developers to fix the MQ performance regression, but this few hundred lines of code hasn't been merged to the mainline kernel and might not end up happening until Linux 4.14.
At present, with the upcoming Linux 4.13 kernel the plan is to use the multi-queue block layer by default.
13 Comments