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?
Odpowiedzi:
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
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”.
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 / ...).