web-dev-qa-db-fra.com

Comment activer et utiliser le planificateur BFQ?

Je viens d'installer la version 4.12 du noyau Linux sur Ubuntu 17.04 en utilisant ukuu (Ubuntu Kernel Update Utility https://doc.ubuntu-fr.org/ubuntu_kernel_upgrade_utility ).

Le fait est que lorsque je vérifie les planificateurs d'E/S disponibles, je n'arrive pas à trouver le BFQ ni le planificateur d'E/S Kyber:

cat /sys/class/block/sda/queue/scheduler
> noop deadline [cfq]

Alors, comment utiliser l'un des nouveaux planificateurs de cette version Linux?

linux-kernelscheduling
18
Sidahmed

Je ne suis pas dans Ubuntu, mais ce que j'ai fait à Fedora peut vous aider.

BFQ est un planificateur blk-mq (Multi-Queue Block IO Queuing Mechanism)), vous devez donc activer blk-mq au démarrage, modifier votre fichier/etc/default/grub et ajouter scsi_mod.use_blk_mq=1 à ton GRUB_CMDLINE_LINUX, voici mon fichier grub, par exemple:

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"

Après cela, vous devez mettre à jour votre grub. Sur Fedora, nous devons utiliser Sudo grub2-mkconfig -o /path/to/grub.cfg, qui varie selon la méthode de démarrage . Sur Ubuntu, vous pouvez simplement exécuter:

Sudo update-grub

Redémarrez, et si vous obtenez ceci:

cat /sys/block/sda/queue/scheduler
[mq-deadline] none

Votre noyau a probablement été compilé avec BFQ en tant que module , et cela peut être le cas également pour Kyber.

Sudo modprobe bfq
Sudo cat /sys/block/sda/queue/scheduler
[mq-deadline] bfq none

Vous pouvez l'ajouter au démarrage en ajoutant un /etc/modules-load.d/bfq.conf fichier contenant bfq.

Il est important de noter que l'activation de blk_mq rend impossible l'utilisation d'ordonnanceurs non blk_mq, vous perdrez donc noop cfq et l'échéance non mq

Apparemment, le système de planification blk_mq ne prend pas en charge les drapeaux d'ascenseur dans grub, les règles udev peuvent être utilisées à la place, avec en prime d'offrir un contrôle plus granuleux.

Créer /etc/udev/rules.d/60-scheduler.rules s'il n'existait pas et ajoutez:

ACTION=="add|change", KERNEL=="sd*[!0-9]|sr*", ATTR{queue/scheduler}="bfq"

Comme indiqué ici si nécessaire, vous pouvez faire la distinction entre les périphériques rotatifs (HDD) et non rotatifs (SSD) dans les règles udev en utilisant l'attribut ATTR{queue/rotational}. Sachez que Paolo Valente, développeur BFQ, a souligné dans LinuxCon Europe que BFQ peut être un meilleur choix que les programmateurs noop ou deadline en termes de garanties de faible latence, ce qui constitue un bon conseil à utiliser pour les SSD aussi.

Comparaison de Paolo: https://www.youtube.com/watch?v=1cjZeaCXIyM&feature=youtu.be

Enregistrez-le, rechargez et déclenchez udev rules:

Sudo udevadm control --reload
Sudo udevadm trigger
24
RomuloPBenedetti

Pour étendre grand réponse RomuloPBenedetti :

Vous pouvez tester si le planificateur bfq est réellement disponible sur un périphérique particulier en utilisant PROGRAM=="/bin/grep -E -q '(^|[[:space:]])bfq($|[[:space:]])' '$sys$devpath/queue/scheduler'" dans la règle udev. Cela remplacera effectivement DRIVERS=="sd|sr" et ne tirez pas si vous oubliez scsi_mod.use_blk_mq=1

Anecdote:

  • PROGRAM - Exécute un programme pour déterminer s'il existe une correspondance; la clé est vraie si le programme revient avec succès; Si aucun chemin absolu n'est donné, le programme devrait vivre dans/lib/udev.
  • $sys - Le point de montage sysfs (/sys).
  • $devpath - Le chemin de développement du périphérique (/ devices/pci/...).
1
Arano-kai