Тех, кто думает о переходе вручную на многопоточный блочный слой, a.k.a. blk-mq, следует предупредить, что все еще есть некоторые регрессии.
www.thomas-krenn.com/en/wiki/Linux_Multi-Queue_...
Короче говоря, при переходе на новый многопоточный блочный слой все еще остаются проблемы пропускной способности и задержки, которые могут возникнуть с любым планировщиком ввода-вывода blk-mq и многими широко используемыми файловыми системами.
В самых наихудших случаях, отмеченных Мелом Горманом, blk-mq может быть примерно на 38% медленнее, чем без его применения, тогда как другие, менее серьезные регрессии также возможны в зависимости от вашей конфигурации системы. Проблемы с MQ указаны в этом списке рассылки:
lkml.org/lkml/2017/8/3/157
Существует новая серия исправлений (marc.info/?l=linux-block&m=150151989915776&w=2), созданная разработчиками Red Hat для исправления регрессии производительности MQ, но эти несколько сотен строк кода пока что ещё не были объединены с основным mainline-кодом ядра, и ещё не факт, что успеют туда добавиться до окончания приёма нововведений в Linux 4.14. В таком случае, добавить эти исправления будет возможно только в Linux 4.15.
Но, интереснее всего то, что в настоящее время в Linux 4.13 уже запланировано начать использовать в по умолчанию этот многопоточный блочный слой.

Linux's Multi-Queue Block Code Still Presenting Some Performance Regressions - Phoronix