Maintenir un sous-système de Linux

Actuellement, le noyau ne propose pas (plus) de configuration concernant l’ordonnanceur par défaut pour des classes de périphériques quelconques. Ces derniers sont essentiellement groupés en deux catégories : ceux qui sont spécialisés dans le traitement de millions d’E/S par seconde et ceux que l’on trouve dans les machines à usage courant. Apparemment, les devs du sous-système des ordonnanceurs en préfèrent les moins complexes ou qui sont dotés de fonctionnalités minimales (mq-deadline, kyber). bfq serait complexe mais beaucoup plus adapté aux périphériques non-spécialisés à de vastes débits en E/S.

Paolo Valente, la personne derrière bfq, a tenté de convaincre Jens Axboe — en charge des ordonnanceurs dans Linux — et compagnie pour qu’il y ait des configurations par défaut, ce qui serait par exemple le cas dans le sous-système Réseau. Jusqu’à maintenant, J. Axboe rejette ces tentatives pour diverses raisons.

Afin d’outrepasser cela et faire adopter bfq à plus de gens, P. Valente a choisi de plutôt travailler avec les distributions étant donné qu’elles ont la capacité de mettre en place des règles udev en vigueur par défaut. Ainsi ai-je regardé ce qui se passe du côté de NixOS et Fedora — je fais tourner ces deux distributions-là. Seule la dernière a des mécanismes en place par défaut quant aux ordonnanceurs. Sans surprise, sous NixOS, en amont on énumère les possibles et en aval, on est invité à écrire ses propres dérivations ... Chez Fedora, bfq est en place par défaut depuis la version 31. Mais cela a nécessité des contorsions :

• J. Axboe a supprimé le champ CONFIG_IOSCHED_DEFAULT dans les options du noyau et, par la même occasion, interdit de définir l’ordonnanceur par défaut à ce niveau-là.
• P. Valente a contourné cela en proposant à Fedora d’introduire bfq par défaut via udev. Zbigniew Jędrzejewski-Szmek y a répondu favorablement mais a voulu définir les paramètres dans systemd-upstream au lieu de patcher le paquet Fedora.
• Lennart Poettering préférait que cela soit fait au niveau du noyau et la boucle recommence ...
• En fin de compte, le paquet systemd sous Fedora a été patché.

La saga n’est pourtant pas terminée ! io.weight et les autres propriétés des cgroups ont été conçues pour cfq. Elles nécessitaient des adaptations afin de fonctionner correctement avec bfq. Fam Zheng a rédigé un patch pour réaliser ce port. Tejun Heo et J. Axboe ont demandé des modifications, P. Valente les a faites mais elles languiraient toujours quelque part en attendant d’atterrir dans une version publique de Linux. Du coup, Kai Krakow a rédigé un contrournement dans systemd qui a été accepté. Ce qui mène à ce constat : afin de se servir d’io.weight et assortis, il faudrait à la fois activer bfq sur le périphérique cible et utiliser une version de systemd qui comporte le patch de K. Krakow.

Pour terminer, en lisant la documentation des cgroups, il me semble qu’un contrôle plus fin des E/S devrait concerner la priorié (IOPS) et le débit (BPS) en même temps. Les commandes que j’ai proposées plus haut ressembleraient alors à ceci :

DOSSIER="$(pwd)"
NOMBRE_ES=...
NOMBRE_OCTETS=...
systemd-run --user --scope \
-p "IOReadIOPSMax=${DOSSIER}${NOMBRE_ES}" \
-p "IOWriteIOPSMax=${DOSSIER}${NOMBRE_ES}" \
-p "IOReadBandwidthMax=${DOSSIER}${NOMBRE_OCTETS}" \
-p "IOWriteBandwidthMax=${DOSSIER}${NOMBRE_OCTETS}" \
processus

Et au lieu de contrôler la priorité en absolu, le faire par périphérique :
-p "IODeviceWeight=${DOSSIER} 100".

Bien entendu, tout ceci est désormais superflu vu que tu as réussi à faire ce que tu voulais et comme tu le souhaitais, via ionice. Disons que ce petit pavé est pour la postérité.