Jak włączyć i korzystać z harmonogramu BFQ?

16

Właśnie zainstalowałem jądro Linuksa w wersji 4.12 na Ubuntu 17.04 za pomocą ukuu (Narzędzie aktualizacji jądra Ubuntu https://doc.ubuntu-fr.org/ubuntu_kernel_upgrade_utility ).

Rzecz w tym, że kiedy sprawdzam dostępne harmonogramy we / wy, nie mogę znaleźć BFQ ani harmonogramu we / wy Kyber:

cat /sys/class/block/sda/queue/scheduler
> noop deadline [cfq]

Jak więc użyć jednego z nowych programów planujących w tej wersji systemu Linux?

Sidahmed
źródło

Odpowiedzi:

22

Nie jestem w Ubuntu, ale to, co zrobiłem w Fedorze, może ci pomóc.

BFQ to program planujący blk-mq (Multi-Queue Block IO Queuing Mechanism), więc musisz włączyć blk-mq podczas uruchamiania, edytować plik / etc / default / grub i dodać scsi_mod.use_blk_mq=1do GRUB_CMDLINE_LINUX, to mój plik grub, ponieważ przykład:

GRUB_TIMEOUT=3
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=false
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="quiet vt.global_cursor_default=0 scsi_mod.use_blk_mq=1"
GRUB_DISABLE_RECOVERY="true"

Następnie musisz zaktualizować swój grub. W Fedorze musimy użyć sudo grub2-mkconfig -o /path/to/grub.cfg, która różni się w zależności od metody rozruchu . W systemie Ubuntu możesz po prostu uruchomić:

sudo update-grub

Uruchom ponownie, a jeśli to otrzymasz:

cat /sys/block/sda/queue/scheduler
[mq-deadline] none

Prawdopodobnie twoje jądro zostało skompilowane z BFQ jako modułem , i tak też może być w przypadku Kybera.

sudo modprobe bfq
sudo cat /sys/block/sda/queue/scheduler
[mq-deadline] bfq none

Możesz go dodać podczas uruchamiania, dodając /etc/modules-load.d/bfq.confplik zawierający bfq.

Ważne jest, aby pamiętać, że włączenie skrętu blk_mq nie jest możliwe, aby użyć harmonogramów spoza blk_mq, więc stracisz noop cfq i termin bez mq

Najwyraźniej system planowania blk_mq nie obsługuje flag windy w grub, zamiast tego można zastosować reguły udev, z dodatkową zaletą oferowania bardziej szczegółowej kontroli.

Utwórz, /etc/udev/rules.d/60-scheduler.rulesjeśli nie istnieje i dodaj:

ACTION=="add|change", KERNEL=="sd*[!0-9]|sr*", ATTR{queue/scheduler}="bfq"

Jak wskazano tutaj, w razie potrzeby można rozróżnić urządzenia obrotowe (HDD) i nierotacyjne (SSD) w regułach udev za pomocą tego atrybutu ATTR{queue/rotational}. Należy pamiętać, że Paolo Valente, programista BFQ, wskazał w LinuxCon Europe, że BFQ może być lepszym wyborem niż programy nooplub deadlineharmonogramy pod względem gwarancji małych opóźnień, co stanowi dobrą radę, aby używać go również w przypadku dysków SSD.

Porównanie Paolo: https://www.youtube.com/watch?v=1cjZeaCXIyM&feature=youtu.be

Zapisz go, załaduj ponownie i uruchom udev rules:

sudo udevadm control --reload
sudo udevadm trigger
RomuloPBenedetti
źródło
3
Chcę tylko zauważyć: nie rób tego na komputerach z Linuksem <4.15, które oczekują, że będziesz w stanie zawiesić się na ram; <4.15 zawiesi wszystkie operacje wejścia / wyjścia po wznowieniu, ponieważ brakuje im poprawek „bezpiecznego wyciszania SCSI”.
Ivan Kozik,
Możesz również mieć problemy z jądrem 4.14, gdzie włączenie blk-mq wydaje się dawać jąderowi „ups” na początku ładowania jądra w niektórych systemach (nie jest to panika z pełnym zatrzymaniem, tylko zerowe zerowanie w jądrze). Możesz tego przegapić, jeśli go nie szukasz, ale jeśli jesteś paranoikiem, może to oznaczać, że coś jest zepsute.
CR.
1
Sugeruję użycie nieco dokładniejszej reguły udev. Kiedy próbowałem tego pokazanego tutaj, udev próbował ustawić harmonogram dla niektórych urządzeń, których nazwy pasują do tego wzorca, ale nie są urządzeniami blokowymi SCSI, które mogą korzystać z harmonogramu BFQ. Zasada, z którą się skończyłem jest następująca: ACTION=="add|change", SUBSYSTEM=="block", DRIVERS=="sd|sr", ATTR{queue/scheduler}!="bfq", ATTR{queue/scheduler}="bfq"unika dopasowania wzorca do nazw urządzeń, co sprawia, że ​​dopasowanie jest dokładniejsze. Nie będzie pasował do urządzeń partycjonujących, ponieważ nie mają atrybutu „kolejka / harmonogram”.
Dan Molding,
3
Należy również zauważyć, że jądra 4.15-4.16 cierpią na dość poważny błąd, w którym aktualizacja schematu partycji dysku podczas korzystania z BFQ może doprowadzić do całkowitego zablokowania I / O. Por .: lkml.org/lkml/2017/12/1/80
Glutanimate
1

Aby rozszerzyć świetną odpowiedź RomuloPBenedetti :

Możesz sprawdzić, czy program planujący bfq jest faktycznie dostępny na określonym urządzeniu, używając PROGRAM=="/bin/grep -E -q '(^|[[:space:]])bfq($|[[:space:]])' '$sys$devpath/queue/scheduler'"reguły udev. To skutecznie zastąpi DRIVERS=="sd|sr"i po prostu nie uruchomi się, jeśli się zapomniscsi_mod.use_blk_mq=1

Drobnostki:

  • PROGRAM- Uruchom program, aby ustalić, czy istnieje dopasowanie; klucz jest prawdziwy, jeśli program powróci pomyślnie; Jeśli nie podano ścieżki bezwzględnej, program powinien żyć w / lib / udev.
  • $sys- Punkt montowania sysfs ( /sys).
  • $devpath - Devpath urządzenia (/ devices / pci / ...).
Arano-kai
źródło