Linux 7.3 change la façon dont l'ordonnanceur traite les cgroups, et si vous exploitez des conteneurs cette phrase compte davantage qu'il n'y paraît. La refonte de Peter Zijlstra, fusionnée pendant la fenêtre 7.3 et rapportée le mercredi 19 août 2026, place EEVDF sur une file d'exécution unique dans certaines situations de cgroup et introduit quatre modes de répartition des poids nommés up, max, concur et tasks, avec concur par défaut. La demande de fusion est inhabituellement franche sur les raisons, qualifiant l'ordonnancement cgroup de problématique et pénible et lui imputant des comportements aberrants comme la mauvaise gestion des tâches reniced.
The short answer
La refonte de l'ordonnancement cgroup de Peter Zijlstra a été fusionnée pendant la fenêtre Linux 7.3 et rapportée le mercredi 19 août 2026. EEVDF utilise désormais une file d'exécution unique dans certaines situations de cgroup, et quatre modes de répartition des poids nommés up, max, concur et tasks ont été ajoutés, avec concur par défaut. Sur un Intel Core i7-2600K avec une Radeon RX 580, le nombre d'images par seconde minimal est passé de 4 à 29 et la latence d'image maximale de 121,2 ms à 30 ms. Aucun changement de configuration n'est nécessaire.
Le plus intéressant dans cette fusion n'est pas le nombre d'images par seconde. C'est la phrase de la demande de fusion qui admet que l'ordonnancement cgroup a toujours été pénible.
Ce qui a été fusionné
Peter Zijlstra, l'ingénieur d'Intel qui maintient l'ordonnanceur Linux, a fait entrer une refonte de l'ordonnancement cgroup dans la fenêtre de fusion de Linux 7.3. Les premiers comptes rendus datent du mercredi 19 août 2026.
Le changement structurel, c'est que l'ordonnancement cgroup utilise maintenant une file d'exécution unique. Plus précisément, EEVDF, la politique Earliest Eligible Virtual Deadline First qui a remplacé le Completely Fair Scheduler, est modifiée pour s'appuyer sur une seule file dans certaines situations de cgroup, au lieu de résoudre ses décisions à travers une hiérarchie imbriquée d'entités de groupe.
Par dessus viennent quatre modes de répartition des poids, ajoutés sous un contrôle cgroup_mode et nommés up, max, concur et tasks. Concur est le mode par défaut, décrit comme le plus précis et aussi comme le plus coûteux. Ce couple résume toute la discussion de conception : le noyau choisit la justesse d'abord et propose les options moins chères à qui aura mesuré une raison de les vouloir.
La motivation affichée n'a rien de discret. Le travail est résumé comme une amélioration de l'ordonnancement cgroup, toujours problématique et pénible, à l'origine de comportements aberrants comme la mauvaise gestion des tâches reniced. Quiconque a déjà vu une valeur de nice rester sans effet dans un conteneur reconnaîtra la plainte.
Les chiffres, et comment les lire
La démonstration tournait sur un Intel Core i7-2600K, un processeur Sandy Bridge de 2011, associé à une AMD Radeon RX 580.
Le nombre d'images par seconde minimal est passé de 4 à 29. La moyenne est passée de 47,5 à 59,2. La latence d'image maximale est tombée de 121,2 millisecondes à 30 millisecondes.
La forme de ces chiffres est plus instructive que leur taille. La moyenne progresse d'environ un quart. Le minimum progresse d'environ sept fois et la latence pire cas d'environ quatre. Quand la queue bouge bien plus que la moyenne, vous regardez une correction de gigue et non un gain de débit, et la gigue est précisément ce que produit une hiérarchie de poids imbriquée quand elle doit trancher une décision sous contention.
C'est aussi pourquoi un test de jeu reste un instrument raisonnable, même pour qui ne joue jamais. Le rythme d'affichage rend la gigue d'ordonnancement visible à l'œil nu à la milliseconde, ce que très peu de métriques serveur permettent. Le jeu est un appareil de mesure.
Pourquoi cela concerne les serveurs et pas seulement les postes
Chaque conteneur que vous exploitez vit dans un cgroup. Chaque service systemd aussi, sur toute distribution moderne, que quelqu'un l'ait décidé délibérément ou non. Le chemin d'ordonnancement cgroup n'est pas un sous système optionnel que l'on peut décliner, c'est le chemin ordinaire.
Conséquence : une réduction de gigue dans la résolution des poids de cgroup touche presque tout. Un service sensible à la latence qui partage un nœud avec un traitement par lots bruyant est exactement le cas de contention visé par la refonte. Il en va de même pour la plainte classique où un conteneur obtient bien ses parts de processeur en agrégé mais où les requêtes individuelles affichent toujours un mauvais quatre vingt dix neuvième centile.
Le détail sur les tâches reniced mérite sa propre note. Si votre orchestration ou vos procédures s'appuient sur les valeurs de nice pour tenir les traitements de fond à l'écart, la demande de fusion vous dit que ce comportement était peu fiable sous cgroups. À revérifier après la mise à jour, car une valeur de nice qui se met à fonctionner correctement est aussi une valeur qui commence à produire un effet que vous n'aviez peut être pas prévu.
Rien de tout cela ne demande de configuration. Concur est le défaut, et les gains rapportés viennent du chemin par défaut. Les trois autres modes attendent que quelqu'un ait caractérisé les cas où la précision ne vaut pas son coût.
Le reste de la demande de fusion
La refonte cgroup arrive accompagnée d'assez d'autres travaux d'ordonnanceur pour que tout le cycle mérite votre attention avant une mise à jour de flotte.
Vincent Guittot a contribué des changements qui abaissent nettement la latence d'ordonnancement des tâches à tranche courte, mesurée avec cyclictest, l'élément le plus directement pertinent pour qui exploite des services proches du temps réel. Une correction concerne l'ordonnancement par grappes sur les processeurs à capacité asymétrique, c'est à dire les puces hybrides d'Intel, sujet auquel ce cycle est déjà revenu plusieurs fois et que nous avons traité quand la correction d'équilibrage a été mise en file pour 7.3. Enfin, l'équilibrage NOHZ privilégie désormais les cœurs totalement inactifs, ce qui se voit sur la latence de queue plutôt que sur un chiffre affiché.
CachyOS, la dérivée d'Arch orientée performance, a annoncé son intention de reprendre ces changements, sans calendrier. C'est en général la voie la plus rapide pour les essayer sur du vrai matériel sans compiler soi même un noyau.
Calendrier et une suggestion
Linux 7.2 est sorti à la mi août 2026, donc 7.3 débute son cycle et la version stable est à environ deux mois. Le cycle 7.2 n'a lui même pas été calme côté ordonnanceur, avec notamment le retour en arrière sur le fair DRM scheduler, ce qui rappelle utilement que des changements d'ordonnanceur de cette taille demandent parfois un second passage.
La suggestion est simple et vaut pour toute refonte d'ordonnanceur. Relevez votre latence d'ordonnancement maintenant, en 7.2, avec un outil auquel vous faites déjà confiance : cyclictest pour la valeur brute, ou votre propre quatre vingt dix neuvième centile de latence de requête sur un nœud en charge normale. Quand 7.3 vous parviendra, comparez à ce relevé. Une refonte aussi structurelle aidera la plupart des charges et en surprendra quelques unes, et le seul moyen de savoir dans quel cas vous êtes, c'est d'avoir mesuré avant.
Sources et pour aller plus loin
- Linux 7.3 Scheduler Improvements: Help For Gaming, Hybrid CPUs, Lower Scheduler Latency, Phoronix, 19 août 2026
- Linux 7.3 patch brings 7x higher minimum FPS in games running on old hardware, Notebookcheck, 20 août 2026
- Linux 7.3 will boost minimum framerates by 7x on older CPUs, XDA Developers, août 2026
- EEVDF, référence Linux Kernel Internals
Questions fréquentes
Quel est le changement réel dans l'ordonnanceur ?
Deux choses, liées entre elles. La première est structurelle : l'ordonnancement cgroup utilise désormais une file d'exécution unique plutôt que la structure imbriquée par groupe sur laquelle il reposait, ce qui signifie qu'EEVDF, la politique Earliest Eligible Virtual Deadline First qui a remplacé CFS, prend ses décisions sur un seul ensemble ordonné d'entités dans les cas concernés au lieu de parcourir une hiérarchie. La seconde est un ensemble de modes de répartition des poids, up, max, concur et tasks, qui contrôlent la façon dont le poids d'un cgroup est réparti sur les processeurs où tournent ses tâches. Le mode par défaut est concur, décrit comme le plus précis et aussi le plus coûteux des quatre. L'effet pratique rapporté est une forte réduction de la gigue de réordonnancement.
Pourquoi un test de jeu vidéo m'apprend il quelque chose sur mes serveurs ?
Parce que la charge est accessoire et le chemin de code ne l'est pas. Le test qui a produit les chiffres phares portait sur un jeu tournant sur du vieux matériel, ce qui constitue un bon cas de stress pour la gigue d'ordonnancement, car une image perdue se voit immédiatement. Ce qui était réellement mesuré, c'est la durée d'attente d'une tâche exécutable quand les poids de cgroup doivent être résolus à travers une hiérarchie. Tout moteur de conteneurs place ses charges dans des cgroups, et systemd fait de même pour les services ordinaires. Si vous avez déjà vu un service sensible à la latence se comporter moins bien dans un cgroup que le même binaire hors cgroup, c'est de cette mécanique qu'il s'agit. Le nombre d'images par seconde est un indicateur, pas le sujet.
Quels chiffres ont réellement été rapportés ?
Sur un Intel Core i7-2600K, un processeur de 2011, associé à une AMD Radeon RX 580, le nombre d'images par seconde minimal est passé de 4 à 29, soit environ sept fois. La moyenne est passée de 47,5 à 59,2. La latence d'image maximale est tombée de 121,2 millisecondes à 30 millisecondes. Lisez le minimum et la latence maximale plutôt que la moyenne : la moyenne a bougé d'environ 25 % tandis que le pire cas a bougé d'un facteur quatre, ce qui est la signature d'une correction de gigue et non d'un gain de débit. Aucune mesure équivalente n'a été publiée pour des charges serveur à ce jour, et c'est la principale raison de mesurer plutôt que de supposer.
Dois je modifier une configuration ?
Non. Concur est le mode par défaut et les améliorations rapportées viennent du chemin par défaut, donc une mise à jour suffit pour obtenir le comportement. Les trois autres modes existent parce que concur est aussi décrit comme le plus coûteux des quatre, ce qui suppose des charges où échanger un peu de précision contre moins de surcoût est le bon choix. Ce compromis n'est pas encore caractérisé publiquement pour des charges serveur, la posture raisonnable consiste donc à garder le défaut, à mesurer votre propre latence d'ordonnancement, et à ne changer de mode que si un chiffre le justifie.
Qu'y a t il d'autre dans la même demande de fusion ?
Le travail de Vincent Guittot qui abaisse la latence d'ordonnancement des tâches à tranche courte, mesurée avec cyclictest, directement pertinent pour qui exploite des services sensibles à la latence. Une correction de l'ordonnancement par grappes sur les processeurs à capacité asymétrique, c'est à dire les puces hybrides d'Intel, thème récurrent de ce cycle. Et une modification qui privilégie les cœurs totalement inactifs lors de l'équilibrage NOHZ, le genre d'ajustement qui se voit sur la latence de queue plutôt que sur un chiffre affiché. Au total, ce cycle d'ordonnanceur est plus chargé que d'habitude, ce qui mérite d'être su avant de mettre à jour une flotte d'un seul coup.