¿Cómo habilitar y usar el planificador BFQ?

16

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?

Sidahmed
fuente

Respuestas:

22

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
Rómulo P Benedetti
fuente
3
Solo quiero señalar: no haga esto en computadoras con Linux <4.15 que espera poder suspender a ram; <4.15 colgará todas las E / S en el currículum porque carecen de las soluciones de "bloqueo seguro de SCSI".
Ivan Kozik
También puede tener problemas en el kernel 4.14 donde habilitar blk-mq parece dar un "oops" al kernel justo al comienzo de cargar el kernel en algunos sistemas (no es un pánico completo, solo una desreferencia nula dentro del kernel). Puede perderlo si no lo está buscando, pero si es paranoico podría ser una señal de que algo está roto.
CR.
1
Sugeriría usar una regla udev un poco más precisa. Cuando probé el que se muestra aquí, udev intentó configurar el programador para algunos dispositivos cuyos nombres coinciden con ese patrón, pero no son dispositivos de bloque SCSI que pueden usar el programador BFQ. La regla con la que terminé es la siguiente: 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".
Dan Molding el
3
También es importante tener en cuenta que los núcleos 4.15-4.16 sufren un error bastante grave en el que actualizar el esquema de partición de una unidad mientras se usa BFQ puede conducir a un bloqueo completo de E / S. Cf .: lkml.org/lkml/2017/12/1/80
Glutanimate
1

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 / ...).
Arano-kai
fuente