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-kernel scheduling

— Sidahmed
source

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 l'ajouter scsi_mod.use_blk_mq=1à votre GRUB_CMDLINE_LINUX, c'est mon fichier grub, comme un 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 en fonction de 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.conffichier 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 indicateurs 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éez /etc/udev/rules.d/60-scheduler.ruless'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 distinguer 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 le noopou les deadlineplanificateurs en termes de garanties de faible latence, ce qui est un bon conseil pour l'utiliser également pour les SSD.

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

— RomuloPBenedetti
source

Je veux juste noter: ne faites pas cela sur des ordinateurs avec Linux <4.15 que vous vous attendez à pouvoir suspendre à ram; <4.15 suspendra toutes les E / S lors de la reprise car elles ne disposent pas des correctifs «mise au repos SCSI sécurisée».

— Ivan Kozik

Vous pouvez également avoir des problèmes sur le noyau 4.14 où l'activation de blk-mq semble donner un "oops" au noyau au début du chargement du noyau sur certains systèmes (ce n'est pas une panique complète, juste une déréférence nulle à l'intérieur du noyau). Vous pourriez le manquer si vous ne le cherchez pas, mais si vous êtes paranoïaque, cela pourrait être un signe que quelque chose est cassé.

— CR.

Je suggère d'utiliser une règle udev légèrement plus précise. Lorsque j'ai essayé celui illustré ici, udev a essayé de définir le planificateur pour certains périphériques dont les noms correspondent à ce modèle, mais ne sont pas des périphériques de bloc SCSI qui peuvent utiliser le planificateur BFQ. La règle avec laquelle je me suis retrouvé est la suivante: ACTION=="add|change", SUBSYSTEM=="block", DRIVERS=="sd|sr", ATTR{queue/scheduler}!="bfq", ATTR{queue/scheduler}="bfq"cela évite la correspondance des motifs avec les noms des appareils, ce qui rend la correspondance plus précise. Il ne correspondra pas aux périphériques de partition car ils n'ont pas l'attribut "queue / scheduler".

— Dan Moulding

Il est également important de noter que les noyaux 4.15-4.16 souffrent d'un bogue assez grave où la mise à jour du schéma de partition d'un lecteur tout en utilisant BFQ peut conduire à un verrouillage complet des E / S. Cf .: lkml.org/lkml/2017/12/1/80

— Glutanimate

Pour étendre la grande réponse de RomuloPBenedetti :

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

Anecdotes:

PROGRAM- Exécuter un programme pour déterminer s'il y a 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 / ...).

— Arano-kai
source