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=1
do 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.conf
plik 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.rules
jeś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 noop
lub deadline
harmonogramy 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ąpiDRIVERS=="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 / ...).źródło