Forum Linux.général Jeu : prioriser les entrées/sorties d'un processus avec cgroupsv2

Posté par ʭ ☯ le 31 mai 2020 à 18:33. Licence CC By‑SA.

Étiquettes :

mai

2020

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 le 02 juin 2020 à 12:34. É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 est IOWeight. Voici par exemple deux unités créés à la volée et lançant deux processus avec une différence dans IOWeight:
```
systemd-run --user --scope -p 'IOWeight=100' processus_1
systemd-run --user --scope -p 'IOWeight=700' processus_2
```
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 ʭ ☯ le 02 juin 2020 à 18:01. É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 le 02 juin 2020 à 21:13. Évalué à 2.
    
    Pourrais-tu indiquer les commandes qui lancent les processus ?
    Une chose semblable (propriétés CPUQuota et MemoryHigh) réagit de la manière attendue chez moi™.
    - [^] # Re: systemd
      
      Posté par ʭ ☯ le 03 juin 2020 à 09:17. É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 le 03 juin 2020 à 14:28. É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 pour cfq 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 de cfq et y basculer avant de tenter de l’utiliser.
        
        Par curiosité, j’ai tenté de voir ce que ça donnerai ici.
        
        grep IOSCHED "/boot/config-$(uname -r)" # CONFIG_MQ_IOSCHED_DEADLINE=y # CONFIG_MQ_IOSCHED_KYBER=y # CONFIG_IOSCHED_BFQ=y # CONFIG_BFQ_GROUP_IOSCHED=y
        
        CFQ n’est pas une option. Il en est de même en scannant ce qui est disponible pour tous les périphériques :
        
        find /sys -name scheduler -exec grep . {} +
        
        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 ʭ ☯ le 04 juin 2020 à 16:18. É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 le 04 juin 2020 à 20:33. É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 ʭ ☯ le 05 juin 2020 à 11:18. É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 le 05 juin 2020 à 22:25. É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è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é.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.

IO