Acabo de instalar Linux kernel versión 4.12 en Ubuntu 17.04 usando ukuu (Ubuntu Kernel Update Utility https://doc.ubuntu-fr.org/ubuntu_kernel_upgrade_utility ).
La cuestión es que, cuando verifico los programadores de E / S disponibles, parece que no puedo encontrar el BFQ ni el programador de E / S Kyber:
cat /sys/class/block/sda/queue/scheduler
> noop deadline [cfq]
Entonces, ¿cómo usar uno de los nuevos planificadores en esta versión de Linux?
Respuestas:
No estoy en Ubuntu, pero lo que hice en Fedora puede ayudarte.
BFQ es un planificador blk-mq (Mecanismo de colas de bloque de E / S de múltiples colas), por lo que debe habilitar blk-mq en el momento del arranque, editar su archivo / etc / default / grub y agregarlo scsi_mod.use_blk_mq=1a su GRUB_CMDLINE_LINUX, este es mi archivo grub, como un ejemplo:
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"
Después de eso, debes actualizar tu grub. En Fedora tenemos que usar sudo grub2-mkconfig -o /path/to/grub.cfg, que varía según el método de arranque . En Ubuntu, simplemente puede ejecutar:
sudo update-grub
Reinicia, y si obtienes esto:
cat /sys/block/sda/queue/scheduler
[mq-deadline] none
Probablemente su núcleo fue compilado con BFQ como módulo , y este puede ser el caso también para Kyber.
sudo modprobe bfq
sudo cat /sys/block/sda/queue/scheduler
[mq-deadline] bfq none
Puede agregarlo en el momento del arranque agregando un /etc/modules-load.d/bfq.confarchivo que contenga bfq.
Es importante tener en cuenta que habilitar blk_mq hace que sea imposible usar planificadores que no sean blk_mq, por lo que perderá noop cfq y la fecha límite no mq
Aparentemente, el sistema de programación blk_mq no admite banderas de elevadores en grub, en su lugar se pueden usar reglas udev, con la ventaja de ofrecer un control más detallado.
Crea /etc/udev/rules.d/60-scheduler.rulessi no existía y agrega:
ACTION=="add|change", KERNEL=="sd*[!0-9]|sr*", ATTR{queue/scheduler}="bfq"
Como se ha señalado aquí , si es necesario se puede distinguir entre rotacionales (HDD) y dispositivos que no son de rotación (SSD) en reglas udev con el atributo ATTR{queue/rotational}. Tenga en cuenta que Paolo Valente, BFQ desarrollador, señaló en LinuxCon Europa que BFQ puede ser una mejor opción que el noopo deadlinelos programadores en términos de garantías de baja latencia, lo que hace un buen consejo para utilizarlo para los SSD también.
Comparación de Paolo: https://www.youtube.com/watch?v=1cjZeaCXIyM&feature=youtu.be
Guárdelo, vuelva a cargar y dispare 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"evita la coincidencia de patrones con los nombres de dispositivos, lo que hace que la coincidencia sea más precisa. No coincidirá con los dispositivos de partición porque no tienen el atributo "cola / planificador".
Para extender la gran respuesta de RomuloPBenedetti :
Puede probar si el programador bfq está realmente disponible en un dispositivo en particular utilizando la PROGRAM=="/bin/grep -E -q '(^|[[:space:]])bfq($|[[:space:]])' '$sys$devpath/queue/scheduler'"regla udev. Esto reemplazará efectivamente DRIVERS=="sd|sr"y simplemente no se disparará si se olvidascsi_mod.use_blk_mq=1
Trivialidades:
PROGRAM- Ejecute un programa para determinar si hay una coincidencia; la clave es verdadera si el programa regresa exitosamente; Si no se proporciona una ruta absoluta, se espera que el programa viva en / lib / udev.$sys- El punto de montaje sysfs ( /sys).$devpath - El devpath del dispositivo (/ devices / pci / ...).