Linux 7.3 modifie le choix d’une tâche dans une hiérarchie de cgroups. La « file unique » ne signifie ni une file mondiale commune à tous les CPU, ni la disparition des poids et de la comptabilité des groupes.
Conserver la hiérarchie, simplifier la sélection
La demande ordonnanceur du 17 août inclut le travail de Peter Zijlstra. Le commit d’implémentation précise le changement : les groupes intermédiaires restent présents pour le suivi de charge et les opérations d’entrée/sortie de file ; EEVDF sélectionne directement les tâches dans la file équitable racine du CPU.
Le poids effectif d’une tâche provient toujours de la hiérarchie. La structure de sélection devient plus plate, tandis que celle du contrôle des ressources demeure. L’auteur précise que cela ne supprime pas immédiatement le coût des opérations hiérarchiques restantes.
Exemple conceptuel : A contient A1 et A2, B contient B1. Les trois tâches peuvent être candidates dans la structure de sélection équitable d’un CPU. Chacune n’obtient pas automatiquement un tiers du processeur : poids des groupes et tâches, état exécutable et autres contrôles comptent encore. Un second CPU possède son propre état d’ordonnancement.
Le défaut change, les anciens réglages comptent
La série ajoute les modes de distribution de poids up, max, concur et tasks, avec concur par défaut. Le commit de changement du défaut avertit que certains utilisateurs ont pu compenser l’ancien comportement en augmentant fortement les poids. Un autre calcul peut modifier l’effet de ces réglages.
« Sans configuration requise » signifie seulement qu’un défaut existe. Cela n’établit pas que poids, affinité CPU et quotas d’un parc sont déjà adaptés. Les prédictions générales de gains en jeu et sur serveurs de l’ancien article dépassaient les preuves disponibles.
Inclure la correction de throttling de septembre
Un correctif du 2 septembre fait examiner à throttle_cfs_rq l’entité courante au niveau hiérarchique concerné. Lire le champ courant de la structure aplatie pour un groupe intermédiaire pouvait manquer son entité active et différer le travail de limitation nécessaire.
Évaluer un instantané du début d’intégration et un noyau corrigé sont donc deux exercices différents. Consignez build réel ou rétroportages de distribution, au lieu d’inscrire seulement « 7.3 » à côté d’une mesure.
Proposition d’évaluation originale : faites cohabiter un service sensible à la latence et une charge CPU contrôlée. Gardez affinité, poids et quotas constants, puis comparez percentiles des requêtes, part CPU obtenue et temps limité par quota. Une moyenne de débit meilleure ne prouve pas que quotas ou latences extrêmes sont corrects. Aucun benchmark d’ordonnanceur n’a été exécuté sur le VPS partagé.
Revue du 8 septembre : annonces et documents techniques vérifiés, évolutions ajoutées et illustration explicative reprise.