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

[tzlom]

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

[temujin]

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

[unxed]

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

[FessAectan]

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

[unxed]

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

[monah_tuk]

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]

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

[monah_tuk]

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

[xalkin]

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

[monah_tuk]

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

[unxed]

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

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

[amarao]

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

[KawaiDesu]

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

[temujin]

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

[AVX]

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

[temujin]

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

[AVX]

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

[ProFfeSsoRr]

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

[saggid]

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

[Kaberc]

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

[freshik]

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

[saggid]

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

[saggid]

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

[saggid]

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

[st0ne_c0ld]

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

[crazylh]

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