Acabo de instalar la versión 4.12 del kernel de Linux en Ubuntu 17.04 usando ukuu (Utilidad de actualización del kernel de Ubuntu https://doc.ubuntu-fr.org/ubuntu_kernel_upgrade_utility ).
La cuestión es que, cuando reviso los programadores de E / S disponibles, no puedo encontrar el BFQ ni el Kyber I / O programador:
cat /sys/class/block/sda/queue/scheduler > noop deadline [cfq] Entonces, ¿cómo usar uno de los nuevos programadores en esta versión de Linux?
Respuesta
No estoy en Ubuntu, pero lo que hice en Fedora puede ayudarte.
BFQ es un blk-mq (Cola de E / S de bloque de múltiples colas Mechanism), por lo que debe habilitar blk-mq en el momento del arranque, editar su archivo / etc / default / grub y agregar scsi_mod.use_blk_mq=1 a su GRUB_CMDLINE_LINUX, este es mi archivo grub, como 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 dependiendo del método de arranque . En Ubuntu, simplemente puede ejecutar:
sudo update-grub Reiniciar, y si obtiene esto:
cat /sys/block/sda/queue/scheduler [mq-deadline] none Probablemente su kernel fue compilado con BFQ como módulo , y este también puede ser el caso de Kyber.
sudo modprobe bfq sudo cat /sys/block/sda/queue/scheduler [mq-deadline] bfq none Puede agregarlo en el momento del arranque agregando un archivo /etc/modules-load.d/bfq.conf que contenga bfq.
Es importante tener en cuenta que habilitar blk_mq hace imposible el uso de programadores que no sean blk_mq, por lo que perderá noop cfq y no mq deadline
Aparentemente, el sistema de programación blk_mq no admite indicadores de elevador en grub, las reglas de udev se pueden usar en su lugar, con la ventaja de ofrecer un control más detallado.
Cree /etc/udev/rules.d/60-scheduler.rules si no existiera y agregue:
ACTION=="add|change", KERNEL=="sd*[!0-9]|sr*", ATTR{queue/scheduler}="bfq" Como se señaló aquí si es necesario, puede distinguir entre la rotacióna l (HDD) y dispositivos no rotacionales (SSD) en reglas udev que utilizan el atributo ATTR{queue/rotational}. Tenga en cuenta que Paolo Valente, desarrollador de BFQ, señaló en LinuxCon Europe que BFQ puede ser una mejor opción que los programadores noop o deadline en términos de garantías de baja latencia, lo que es un buen consejo para usarlo también para SSD.
Comparación de Paolo: https://www.youtube.com/watch?v=1cjZeaCXIyM&feature=youtu.be
Guárdelo, vuelva a cargar y active udev rules:
sudo udevadm control --reload sudo udevadm trigger Comentarios
Responder
Para extender excelente respuesta de RomuloPBenedetti :
Puede probar si el programador bfq está realmente disponible en un dispositivo particular usando PROGRAM=="/bin/grep -E -q "(^|[[:space:]])bfq($|[[:space:]])" "$sys$devpath/queue/scheduler"" en la regla udev.Esto reemplazará efectivamente DRIVERS=="sd|sr" y simplemente no disparará si uno olvidó scsi_mod.use_blk_mq=1
Trivia:
-
PROGRAM– Ejecuta 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 de sysfs (/sys). -
$devpath– La ruta de desarrollo del dispositivo (/ devices / pci / …).
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 los dispositivos, lo que hace que la coincidencia sea más precisa. Ganó ' t coincidir con los dispositivos de partición porque no ' no tienen la " cola / El atributo del programador ".echo bfq > /sys/block/sda/queue/schedulercomo root. (sudo no me funcionó en Ubuntu 18.04) Esto debería hacerlo efectivo de inmediato.