temujin Sep 5 2017 at 23:51

Планировщик ввода / вывода BFQ лучше

5 min

25K

Open source*System Analysis and Design*Algorithms*Development for Linux*

+26

Comments 26

tzlom Sep 6 2017 at 02:15

Хорошо написано, спасибо.
А про планировщик задач можете написать?

temujin Sep 6 2017 at 09:38

Спасибо за отзыв. Постараюсь, там тоже история заковыристая, но на данный момент бурлений вроде нет.

unxed Sep 23 2017 at 19:06

Как там MyQSS поживает? Ему в ванили всё так же не рады?

FessAectan Sep 6 2017 at 03:47

Судя по данному тесту — www.phoronix.com/scan.php?page=article&item=linux-412-io&num=1
не так то он хорош (в контексте теста, т.е. для ssd)
Интересно было бы посмотреть аналогичный тест из демо-ролика для SSD

unxed Sep 23 2017 at 19:08

Там только-только пофиксили пачку критичных багов, как раз с подачи фороникса. Те обещали перепроверить. Вот, например:
github.com/xanmod/linux/compare/be5cf8d5cfed14d39dbe56415f6933b41e1870a4...4bef913a5e532b0b034d2b2ff31203d637e3cdf4

monah_tuk Sep 6 2017 at 06:53

multiqueue API

только оно поломано в 4.12. Проявляется, к примеру, в полном зависании при выходе из сна. Выключение — решает проблему.

Первые сборки 4.12 в Manjaro были с blk-mq. Теперь оставили только в экспериментальном 4.13, где так же есть данная проблема.

В них планировщик BFQ используется по умолчанию.
Manjaro

Уже не совсем правда. При включенном blk-mq дефолтный планировщик теперь mq-deadline. А согласно тестированию фороникса, BFQ уже далеко не в лидерах (ссылка в предыдущем коментарии), по крайней мере для SSD.

Стоит отметить, что при включенном blk-mq CFQ перестаёт быть доступным (по крайней мере для HDD) и среди возможных вариантов (мы про Manjaro): mq-deadline, kyber (тоже появился в 4.12), noop и bfq-mq. Лично я настроил правила udev и в данной конфигурации для HDD используется bfq-mq, тогда как для SSD — mq-deadline. Для системы без blk-mq — дефолтный планирощик (bfq-sq).

А Kyber, судя по всему, должен быть хорош для современных SSD дисков. Но у меня SSD нет.

xalkin Sep 7 2017 at 07:54

В моем случае проявляется поломанность более капитально: при значительной i/o нагрузке система фризится так, что даже alt-sysrq не помогает. И происходит это еще при старте системы :(

monah_tuk Sep 7 2017 at 10:03

Да, в моём случае SysRq тоже не помогает. Так что природа, судя по всему — одна и та же.

xalkin Sep 7 2017 at 12:14

Есть надежда, что в 4.14 пофиксят.

monah_tuk Sep 6 2017 at 06:57

Кстати, в статье явно не хватает ссылки: Two new block I/O schedulers for 4.12

unxed Sep 20 2018 at 17:55

Там пишут, что kyber — это когда нужна высокая производительность, а bfq — когда нужны низкие задержки.

Забавно, что выводы selectel'а полностью противоположные. И кому верить?

amarao Sep 6 2017 at 11:43

Очень заинтересовали. Если дойдут руки, сравню на серверной синтетике.

KawaiDesu Sep 6 2017 at 13:54

Поделитесь потом?

temujin Sep 6 2017 at 14:06

Присоединяюсь, хотелось бы увидеть больше замеров: синтетических и прочих.

AVX Sep 6 2017 at 15:46

Подскажите, для Mageia — с какой версии планировщик уже по умолчанию BFQ, а с какой он есть, но не по умолчанию? (и есть ли вовсе)
Интересует Mageia 5, Mageia 2.
Хотелось бы проверить хотя бы на времени загрузки (ну и на типовом использовании): Mageia 5 у меня на быстром компе с SSD диском, Mageia 2 на старом двухъядернике с древним HDD 20GB.

temujin Sep 6 2017 at 16:57

Скорее всего с последней 6-й, так как ядро 4.12 вышло лишь в июле. Но на старой можно использовать кернел последней версии для проверки, если у вас только 5-я версия имеется.

AVX Sep 6 2017 at 18:53

У меня на 5й сейчас ядро 4.4.82, значит, пока не получится.
Кстати, я и не заметил как 6я магия вышла из беты…

ProFfeSsoRr Sep 6 2017 at 18:25

Хочу добавить, что Arch'евский пакет linux-ck в AUR великолепен, если хочется собрать своё ядро, очень удобно оформлен PKGBUILD. И даже выключить в нём BFQ не проблема, если захочется :)

saggid Sep 6 2017 at 23:54

Спасибо, я в итоге перешёл на ядро от Repo-ck из-за вашей наводки) Пока что работается как минимум не хуже чем на основном ядре.

Kaberc Sep 6 2017 at 20:20

Проверил у себя, для моего NVMe SSD никакого планировщика не используется, хотя доступны mq-deadline, kyber и bfq. Не могли бы вы пояснить ситуацию с NVMe? Так и не смог нагуглить никакой информации по этому вопросу.

freshik Sep 7 2017 at 07:54

Это, скорее всего, потому, что для NVMe SSD с его большой внутренней очередью и низким latency планировщик в принципе не нужен: лучше отправлять запросы сразу напрямую.

saggid Sep 6 2017 at 21:12

Опасная какая-то тема)) Попробовал у себя на арч линуксе на ноуте с SSD. Через две перезагрузки ноут перестал нормально загружаться и стал выдавать сообщения подобные сообщениям в этом треде. Вернулся я обратно на cfq, в общем)

saggid Sep 7 2017 at 01:14

Хотя на вышеуказанном ядре Repo-ck всё пока что работает нормально в том числе и на bfq планировщике.

saggid Sep 7 2017 at 03:35

А нет… казалось, что с вынутым кабелем зарядки ноут не стартует тоже. В общем… По-моему, стандратное ядро без дополнительных навесов — всё-таки вещь тоже хорошая...) По крайней мере работает во всех ситуациях стабильно и без глюков.

st0ne_c0ld Sep 6 2017 at 23:07

глядя на последний график, остается впечатление, что под OLTP БД deadline всё ещё самый подходящий.

crazylh Sep 8 2017 at 12:26

Только надо включать этот планировщик аккуратно, потому что включение multiqueue API приводит к отключению non-multiqueue планировщиков (noop, cfq, deadline)

Show the best of all time