BFQ в Debian на ядре 4.12

Там не тот BFQ, что обычно. Он для blk-mq, то есть для многопоточных носителей, типа SSD на NVMe

А SSD на SATA не многопоточные что ли?

Можно. Добавь scsi_mod.use_blk_mq=1 в grub.cfg и создай правило udev /etc/udev/rules.d/60-scheduler.rules:

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="bfq"

Да, ещё в /etc/modules-load.d/modules.conf добавь bfq.

А не ты ли использовал blk-mq с hdd?

Прочитал вот https://www.reddit.com/r/archlinux/comments/4eu5ii/does_anyone_use_blkmq_on_a... и призадумался, всегда ли это хорошо?..

Благодарю, завелось.

А для флешек сойдет? Или профита не будет?

Арийско верно - станет нижеследующее:

в строке запуска кернел, `scsi_mod.use_blk_mq=1'

и убедиться в работе,

blitz@inode ~ % cat /sys/block/sda/queue/scheduler
mq-deadline kyber [bfq] none
blitz@inode ~ % cat /sys/block/sdb/queue/scheduler
mq-deadline kyber [bfq] none

Годно и для SSD. Для флешек - не ведаю.

Тем не менее работает и с саташными носителями. А sq-blk в мейнлайне у нас все равно нет. Впрочем, я никакой разницы по сравнению с CFQ не разглядел.

В смысле, writeback throttling не предотвращает затупы на смешанной нагрузке с записью?

Это было бы печально.

Запусти линковку Firefox с LTO и попробуй одновременно глянуть, скажем на видео Тытруба.

Разницу, с bfq kernel - оценишь сразу.

Для флешек хорошо подходит
vm.dirty_bytes = 66554432
vm.dirty_background_bytes = 33554432

Интересно.

Но эти же, vm.xxx - будут влиять и на работу HDD?

Ага, а еще и планировщик задач сменить до кучи.

Нафиг это простому смертному. Прирост от смены HDD на SSD ощущается, а от программного тюнинга едва ли.

Ради интереса твоего, запусти программу interbench - для проверки отзывчивости кернелов.

Долго идут тесты. И если кратко - BFQ/BFS/MuSQQ - побеждают в тестах responsability/отзывчивости кернелов.

И вот это - -O3 и falign=16, такая сборка кернела у Nazi Blitz. Работает, арийско надёжно и шустро.

Enables alignments optimization
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -236,7 +236,7 @@
 LDFLAGS := -m elf_$(UTS_MACHINE)

 # Speed up the build
-KBUILD_CFLAGS += -pipe
+KBUILD_CFLAGS += -falign-functions=16 -falign-jumps=16 -falign-loops=16 -falign-labels=16 -fno-builtin -pipe
 # Workaround for a gcc prelease that unfortunately was shipped in a suse release
 KBUILD_CFLAGS += -Wno-sign-compare
 #

Enables gcc -O3 optimization
--- a/Makefile
+++ b/Makefile
@@ -632,6 +632,9 @@
 KBUILD_CFLAGS  += $(call cc-option,-fno-delete-null-pointer-checks,)
 KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)

Нет.

Впрочем, я никакой разницы по сравнению с CFQ не разглядел.

На HDD или SSD?

На SSD

Странно, мне noop на ssd показался отзывчивей. Bfq пока не распробовал.

На каких задачах - noop отзывчивей?
И что показывает interbench? Знаю, тебе лень проверять по независимым тестам.

Верю, что тесты покажут разницу. Но на практике существенных изменений от смены I/O планировщиков не увидел. Задачи обычные: компиляция, git, браузер, музыка, сериалы.

Возможно, что BFQ и поможет от 12309. Большие файлы, тем более на флешку, копирую очень редко. А вот мильон мелких файлов при работе с git - обычное дело.

Внезапно при работе с hdd. При включенном zswap во время своппинга с cfq подвисает немного, когда как с noop своппинг происходит незаметно. Тесты не гонял ибо лень и в реальных десктоп-задачах может может быть некоторая разница.
Кстати, на разном железе все эти планировщики дают довольно разные результаты. Раньше экспериментировал с разными патченными ядрами в основном на древних ноутах, на них bfq был гораздо отзывчивей, когда как на современном железе никакой разницы не замечал.

> Задачи обычные: компиляция, git, браузер, музыка, сериалы.

Let us, не путать мёд с мухами!
Одновременно запускал - компиляция и браузеры?

Поделись пожалуйста, какой load average был у тебя в таком режиме?

Одновременно запускал - компиляция и браузеры?

Ну да. Тормоза есть. Пробовал bfq, затем bfq+vrq (http://cchalpha.blogspot.ru/ muqss для 4.12 тогда еще не был готов), из опций ядра только таймер выставлял в 100hz и включал vrq. Плацебо какое-то, интерактивности особо не прибавило. Впрочем, колом система итак не вставала.

Значительно больше дал earlyoom. он избавил систему от фриза при кривых системах сборки (когда -j ведет к отжиранию всей памяти).

И конечно очень много дала смена HDD на SSD.

Поделись пожалуйста, какой load average был у тебя в таком режиме?

Буду в следущий раз насиловать систему, отпишу. Но нагрузка обычно полная, на все ядра.

Небольшой отчет по поводу использования bfq на десктопном ноутбуке с hdd. Супер-отзывчивости во времени запуска приложений я не заметил, всё вроде так же как на noop. Из приятных фишек - при просмотре жирного bdrip и параллельной работе с диском (запустил перехеширование торрентов) никаких лагов воспроизведения нет (mpv), когда как с noop или cfq проскакивают лаги даже если диск занят только воспроизведением фильма. Никаких минусов замечено не было.
Так что рекомендую попробовать bfq для десктоп задач.