L'ingénieur Linux de NVIDIA Andrea Righi a posté une nouvelle série de correctifs d'ordonnancement le 31 août 2026, et elle poursuit un fil ouvert en mars. Le problème est propre à NVIDIA Vera, mais sa forme ne l'est pas. Quand le microcode annonce des capacités légèrement différentes pour des processeurs qui ont aussi le SMT activé, le noyau active un chemin de code conçu pour les cœurs grands et petits, et qui ignore totalement ce qu'est un fil d'exécution occupé. Les correctifs de mars ont appris à ce chemin à préférer les cœurs entièrement libres. Cette nouvelle série va plus loin, en désignant un frère préféré dans chaque cœur.
The short answer
L'ingénieur NVIDIA Andrea Righi a posté une seconde série de correctifs d'ordonnancement pour NVIDIA Vera. La plateforme annonce de petits écarts de capacité entre processeurs et fait aussi tourner le SMT, ce qui active les chemins SD_ASYM_CPUCAPACITY du noyau en les laissant aveugles aux hyperfils occupés. Une série de mars a corrigé le pire en préférant les cœurs entièrement libres. La nouvelle série désigne PE0 comme frère préféré de chaque cœur Olympus via SD_ASYM_PACKING et apprend à la sélection de processeur libre à respecter cette priorité, en choisissant d'abord un cœur libre puis le frère de plus haute priorité à l'intérieur.
Les défauts d'ordonnancement ressemblent rarement à des défauts. Rien ne plante, aucune ligne de journal n'apparaît, et chaque processeur se déclare occupé. La charge met simplement deux fois plus de temps que ce que le matériel promet, et quelqu'un passe une semaine à prouver que ce n'est pas la faute de l'application.
C'est en gros l'histoire de la série de correctifs qu'Andrea Righi, chez NVIDIA, a postée le 31 août 2026, et de celle de mars sur laquelle elle s'appuie. La plateforme concernée est NVIDIA Vera et elle n'est pas encore commercialisée, mais le mécanisme mérite d'être compris par quiconque fait tourner du SMT sur quoi que ce soit.
Deux fonctions du noyau qui n'étaient pas censées se croiser
Le noyau possède un drapeau, SD_ASYM_CPUCAPACITY, qu'il positionne quand les processeurs d'un domaine d'ordonnancement n'ont pas tous la même capacité. Il existe pour l'agencement grands et petits cœurs répandu dans le silicium mobile, où certains cœurs sont réellement, structurellement plus rapides, et où l'ordonnanceur doit placer le travail sensible à la latence sur les rapides.
Le noyau possède aussi le SMT, où deux processeurs logiques partagent un cœur physique et donc ses ressources d'exécution.
Sur Vera, les deux sont actifs en même temps. Le microcode expose des variations mineures de fréquence sous forme d'écarts de capacité, ce qui suffit à lever le drapeau de capacité asymétrique, et le SMT est activé. La logique de sélection de processeur libre en capacité asymétrique tourne alors sur une topologie pour laquelle elle n'a jamais été écrite, et elle commet une erreur précise : elle lit la capacité nominale d'un processeur logique et la prend pour du calcul disponible, sans vérifier si le frère qui partage ce cœur physique est déjà saturé.
Le résultat est un ordonnanceur qui place une tâche sur la moitié libre d'un cœur occupé pendant qu'un cœur entièrement libre attend à côté. NVIDIA a chiffré le coût jusqu'à environ 2x sur des charges gourmandes en processeur.
Mars : cesser de faire le mauvais choix
La première série, postée fin mars 2026, était corrective. Elle ajoutait la conscience du SMT aux chemins de capacité asymétrique, avec une règle énoncée sans détour : préférer les cœurs entièrement libres, et ne pas traiter les frères SMT partiellement libres comme des cibles à pleine capacité là où cela tromperait l'équilibrage de charge.
Cette règle n'est pas nouvelle dans le noyau. L'ordonnancement SMT symétrique ordinaire la connaît depuis des années, ce qui rend le défaut un peu gênant et aussi très banal. Deux sous-systèmes se comportaient correctement isolément, et leur combinaison est tombée dans un trou dont aucun des deux n'était propriétaire.
Les ingénieurs de NVIDIA ont évalué les alternatives avant d'écrire ce correctif, et le raisonnement mérite d'être repris parce qu'il s'applique à beaucoup de particularités de plateforme. Ils pouvaient égaliser les capacités dans le microcode, ce qui aurait empêché le drapeau de se lever. Ils pouvaient normaliser les capacités dans le noyau, avec le même effet de façon plus centrale. Ils pouvaient activer l'empaquetage asymétrique à la place. Ils ont conclu qu'apprendre le SMT au chemin existant donnait de meilleurs résultats que ces contournements, ce qui est la réponse la plus difficile et la plus durable.
Août : commencer à faire le bon
La nouvelle série ne rebouche pas le même trou. Elle exprime une préférence qui n'existait pas.
Elle désigne PE0 comme frère préféré d'un cœur Olympus, via SD_ASYM_PACKING, le mécanisme que le noyau utilise déjà pour dire que certains processeurs doivent être remplis avant d'autres. Puis elle apprend aux chemins de sélection de processeur libre de l'ordonnanceur équitable à honorer cette priorité SMT asymétrique.
L'ordre des opérations qui en résulte se fait en deux temps, et mérite d'être énoncé explicitement parce que c'est ce qui rend la conception propre. L'ordonnanceur choisit d'abord un cœur libre selon ses règles existantes de placement et de capacité, inchangées. Ensuite seulement, ayant choisi un cœur, il prend le frère disponible de plus haute priorité à l'intérieur. Sélection du cœur et sélection du frère restent des préoccupations séparées, et c'est pourquoi cela se compose avec le travail de mars au lieu de le remplacer.
Pourquoi un frère devrait être préféré à l'autre sur un cœur physique est un détail matériel propre à Olympus, et NVIDIA est la partie qui le connaît. Ce qu'il manquait au noyau, c'était un moyen de se le faire dire, et SD_ASYM_PACKING est ce moyen.
La partie qui concerne le matériel que vous possédez
Vera n'est pas achetable, donc la portée immédiate est limitée. Deux choses se généralisent.
La première, c'est que ce correctif touche du code partagé de l'ordonnanceur équitable. Les chemins de capacité asymétrique et de sélection de processeur libre ne sont pas propres à un constructeur, donc une fois cela intégré, toute plateforme qui lève les mêmes drapeaux hérite du nouveau comportement. Si vous exploitez une topologie processeur hétérogène avec SMT activé, vous êtes dans cet ensemble, que vous ayez entendu parler des cœurs Olympus ou non.
La seconde, c'est le mode de défaillance lui-même, et c'est celui qu'il faut retenir. Une table de microcode annonçant des capacités légèrement différentes a activé silencieusement tout un corpus de logique d'ordonnancement destiné à un autre type de machine. Rien ne l'a signalé. Il n'y a pas de message de démarrage annonçant que l'ordonnancement en capacité asymétrique est désormais en jeu. On l'apprend en mesurant, en remarquant un chiffre faux d'un facteur deux, et en lisant les sources de l'ordonnanceur.
Si vous poursuivez une performance qui ne correspond pas au matériel sur un système SMT, /sys/kernel/debug/sched/domains vous dira quels drapeaux portent réellement vos domaines, et c'est un chemin plus rapide vers la réponse que de profiler l'application une fois de plus.
Pour le contexte plus large de ce matériel, notre couverture de la plateforme Vera Rubin et de ce qui a atterri dans la fenêtre de fusion de Linux 7.3 touche le même coin de l'écosystème.
Sources et pour aller plus loin
- NVIDIA Posts Linux Scheduler Patches To Further Boost SMT Performance On NVIDIA Vera, Phoronix, 31 août 2026
- Linux Patches Posted To Fix ~2x Performance Drop For CPU Workloads On NVIDIA Vera Rubin, Phoronix, 26 mars 2026
- PATCH v2 0/2 sched/fair: SMT-aware asymmetric CPU capacity, LKML
- Hot Chips 2026: Nvidia breaks down 88-core Vera CPU, Tom's Hardware
Questions fréquentes
Quel est exactement le défaut corrigé ?
La capacité nominale par processeur logique surestime le calcul réel quand l'autre frère SMT du même cœur physique est occupé, parce que le cœur ne délivre pas sa pleine capacité nominale à deux fils simultanément. Les chemins de capacité asymétrique du noyau, conditionnés par SD_ASYM_CPUCAPACITY, ont été écrits pour des plateformes où les écarts de capacité viennent de types de cœurs différents, pas de la contention. Ils traitent donc un frère SMT partiellement libre comme une destination à pleine capacité et y placent volontiers une tâche pendant qu'un cœur totalement libre reste inutilisé. Sur la plateforme de NVIDIA, cette erreur coûtait jusqu'à environ 2x sur des charges gourmandes en processeur avant le correctif de mars.
Pourquoi un chemin de capacité asymétrique s'active-t-il sur un processeur serveur ?
Parce que le microcode expose de petits écarts de capacité entre processeurs, et que le noyau ne distingue pas un petit écart d'un grand. Il voit des capacités non uniformes, positionne SD_ASYM_CPUCAPACITY, et active une logique bâtie pour l'agencement grands et petits cœurs du silicium mobile. Ajoutez le SMT par-dessus et vous obtenez une combinaison contre laquelle le code n'a jamais été écrit : capacité asymétrique et hyperfils actifs en même temps. Les ingénieurs de NVIDIA ont envisagé d'autres approches, dont l'égalisation des capacités dans le microcode ou dans le noyau, et ont conclu qu'ajouter la conscience du SMT au chemin existant donnait de meilleurs résultats.
Qu'ajoute la nouvelle série par rapport au travail de mars ?
La série de mars était défensive, elle empêchait l'ordonnanceur de considérer un cœur à moitié occupé comme une bonne cible et lui faisait préférer les cœurs entièrement libres. La nouvelle série exprime au contraire une préférence positive. Elle désigne PE0 comme frère préféré d'un cœur Olympus via SD_ASYM_PACKING, le mécanisme déjà employé ailleurs dans le noyau pour dire que certains processeurs doivent être remplis avant d'autres, et apprend aux chemins de sélection de processeur libre à honorer cette priorité SMT asymétrique. L'ordre se fait en deux temps : choisir un cœur libre selon les règles existantes, puis choisir le frère disponible de plus haute priorité à l'intérieur.
Cela concerne-t-il des machines achetables aujourd'hui ?
La plateforme visée est NVIDIA Vera, qui n'est pas encore disponible publiquement, donc la réponse directe est non. La réponse indirecte est plus intéressante. Ces changements touchent du code partagé de l'ordonnanceur équitable, dans les chemins de capacité asymétrique et de sélection de processeur libre, donc une fois intégrés ils s'appliquent à toute plateforme qui déclenche les mêmes drapeaux. Quiconque exploite une topologie processeur hétérogène avec SMT activé fait partie de l'ensemble concerné, et cette classe de défaut, un écart de capacité annoncé par le microcode qui active silencieusement un comportement d'ordonnancement conçu pour autre chose, n'est propre à aucun constructeur.
Qu'est-ce que NVIDIA Vera ?
C'est le processeur serveur Arm de NVIDIA, détaillé à Hot Chips 2026, bâti autour de 88 cœurs Olympus avec multithreading spatial et associé à de la mémoire SOCAMM2 annoncée à 1,2 To par seconde. C'est la moitié processeur de la plateforme Vera Rubin, destinée à voisiner les GPU Rubin dans les baies de centres de données pour l'IA. Ce contexte explique l'urgence du travail d'ordonnancement : une régression de 2x sur des tâches liées au processeur est désagréable sur un poste de travail et inacceptable sur du matériel déployé à la baie pour alimenter des accélérateurs qui ne doivent pas rester inactifs.