Je propose un jeu pour occuper un WE trop calme : réussir à prioriser deux lectures simultanées sur un même disque dur. L'idée est de lire un premier fichier le plus vite possible en priorité basse, mais de ralentir cette lecture quand une seconde lecture simultanée est lancée en priorité haute.
Des pistes :
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html
https://andrestc.com/post/cgroups-io/
PS: oui j'abuse, j'essaye de gamifier pour un truc que je n'arrive pas à faire. Mais promis, tout le monde sera content à la fin ;-)
# systemd
Posté par gipoisson . Évalué à 3.
Une des différences entre les première et deuxième versions des cgroups réside dans la capacité de créer des branches dans la hiérarchie. En v2, la seule hiérarchie qui existe est gérée par une seule entité ; du moins, dans l’implémentation de systemd. Un système faisant tourner ce dernier lui délègue tout ce qui a trait aux cgroups — leur création, suppression, modification …
Pour le cas qui t’intéresse, essaie de créer deux unités semblables presque en tout, sauf dans le paramètre « priorité des E/S. » qui, d’après ce que j’ai tiré de la documentation, serait
io.weight
.systemd.resource-control(5)
explique la correspondance entre les API du noyau et systemd ; on peut notamment y lire que l’option correspondant àio.weight
estIOWeight
. Voici par exemple deux unités créés à la volée et lançant deux processus avec une différence dansIOWeight
:Ton post indique que tu voudrais plus que ça : définir l’IOWeight d’une unité conditionnellement à la valeur du même paramètre d’une autre unité. Il faudrait alors écrire de vrais fichiers unit qui spécifient cette dépendance.
P.S. Au cas où tu n’utiliserais pas systemd, toutes mes plates.
P-P.S. Au cas contraire, si la v2 casse des choses qui tournaient bien en v1 sur une machine ayant systemd, tu peux booter en indiquant au noyau d’utiliser v1 et systemd respectera ça. La hiérarchie des cgroups utilisée pendant une session donnée est, par exemple, consultable avec
systemctl --version #⇒ default-hierarchy=unified
.P-P-P.S. Je touche à ces questions de très loin, i.e. ai compétences proches du néant dans le domaine, pourrai pas aider au-delà de ce qui précède.
[^] # Re: systemd
Posté par ʭ ☯ . Évalué à 2.
Merci d'avoir joué, si c'est la bonne réponse, cela ne se voit pas : avec deux processus lancés en poids 1 et poids 10000, il y a toujours strictement la même bande passante pour les deux.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: systemd
Posté par gipoisson . Évalué à 2.
Pourrais-tu indiquer les commandes qui lancent les processus ?
Une chose semblable (propriétés
CPUQuota
etMemoryHigh
) réagit de la manière attendue chez moi™.[^] # Re: systemd
Posté par ʭ ☯ . Évalué à 3.
C'est bien le problème : pour les IO, on n'obtient pas le résultat escompté!
J'ai cru comprendre que seul l'ordonanceur CFQ y obéit :
```
IO
The "io" controller regulates the distribution of IO resources. This
controller implements both weight based and absolute bandwidth or IOPS
limit distribution; however, weight based distribution is available
only if cfq-iosched is in use and neither scheme is available for
blk-mq devices.
```
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: systemd
Posté par gipoisson . Évalué à 2.
Ah oui ! Je n’avais pas lu ce paragraphe. Je fais la même lecture que toi : le
cgroup
que tu veux utiliser n’est valable que pourcfq
qui, après un rapide tour sur le web, a été retiré des récentes versions du noyau. Donc, il vaudrait mieux chercher à installer/activer le pilote decfq
et y basculer avant de tenter de l’utiliser.Par curiosité, j’ai tenté de voir ce que ça donnerai ici.
CFQ n’est pas une option. Il en est de même en scannant ce qui est disponible pour tous les périphériques :
Bref, tente d’abord de configurer CFQ si ton noyau est compilé avec, sinon il faudra compiler Linux dans une ancienne version.
[^] # Re: systemd
Posté par ʭ ☯ . Évalué à 2.
Le but du jeu est que ça marche partout… j'ai l'impression qu'on a perdu la fonctionnalité de ionice avec le temps… je suis le seul à trouver dommage qu'une simple mise à jour du système fasse ramer tout l'ordi?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: systemd
Posté par gipoisson . Évalué à 1.
Hier, après une lecture en diagonale d’une volée de pages sur le web, des choses ont piqué ma curiosité et j’aimerais approfondir un peu. J’ai mis des marques-pages sur ces pages, pense qu’une solution est là-dedans, n’ai pas encore eu le temps de les relire et reviendrai là-dessus d’ici samedi (une longue phrase pour qualifier la procrastination …).
Entre-temps, si l’ordonnanceur du périphérique sur lequel tu fais les E/S est
bfq
, tu peux explorer le sujet et trouveras sans doute la solution avant mon prochain post.[^] # Re: systemd
Posté par ʭ ☯ . Évalué à 3.
Merci pour la piste. En fait, ionice fonctionne toujours avec un ordonnanceur qui fait de la priorité.
La solution est donc pour moi :
echo bfq > /sys/devices/pci0000:00/0000:00:17.0/ata1/host0/target0:0:0/0:0:0:0/block/sda/queue/scheduler
ionice -c3 processus_lent
Et j'obtiens effectivement le résultat escompté. Mon problème est tout simplement issu de ma distribution qui n'active pas bfq par défaut, au moins pour les disques rotatifs.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# Maintenir un sous-système de Linux
Posté par gipoisson . Évalué à 1.
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èglesudev
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 :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à.bfq
par défaut viaudev
. Zbigniew Jędrzejewski-Szmek y a répondu favorablement mais a voulu définir les paramètres danssystemd
-upstream au lieu de patcher le paquet Fedora.systemd
sous Fedora a été patché.La saga n’est pourtant pas terminée !
io.weight
et les autres propriétés descgroups
ont été conçues pourcfq
. Elles nécessitaient des adaptations afin de fonctionner correctement avecbfq
. 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 danssystemd
qui a été accepté. Ce qui mène à ce constat : afin de se servir d’io.weight
et assortis, il faudrait à la fois activerbfq
sur le périphérique cible et utiliser une version desystemd
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 :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é.Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.