Les performances d'un ordinateur ne dépendent pas uniquement de la vitesse de son processeur. Elles reposent aussi sur la capacité du système d'exploitation à distribuer efficacement le travail entre les différents cœurs disponibles.

Sur les architectures modernes, cette décision est devenue particulièrement complexe.

Certains processeurs mélangent plusieurs types de cœurs, avec des fréquences et des caractéristiques de cache différentes. Le noyau Linux doit alors choisir entre de nombreuses stratégies : exploiter le cœur le plus rapide, éviter de déplacer inutilement les tâches ou maintenir leurs données dans un cache partagé.

Ces objectifs peuvent entrer en conflit.

C'est précisément ce qui s'est produit avec une régression découverte sur l'AMD Ryzen AI 9 HX 370 et détaillée par Phoronix le 26 octobre 2026.

Une optimisation introduite dans l'ordonnanceur pouvait privilégier la proximité du cache au détriment d'un déplacement vers des cœurs plus performants.

La correction fait désormais partie du développement de Linux 7.4.

Un Ryzen AI 9 HX 370 avec deux catégories de cœurs

Le processeur Ryzen AI 9 HX 370 appartient à la famille AMD Strix Point.

Il utilise une architecture hybride composée de douze cœurs physiques et de vingt-quatre threads.

Quatre cœurs reposent sur l'architecture Zen 5 classique, tandis que huit autres utilisent Zen 5c.

Les deux familles partagent de nombreux éléments architecturaux, mais ne disposent pas des mêmes contraintes de fréquence et d'organisation du cache.

Sur la configuration examinée dans le rapport technique, les cœurs Zen 5 peuvent atteindre environ 5,1 GHz.

Les Zen 5c sont limités à environ 3,3 GHz.

Leur domaine de cache L3 est également plus petit : 8 Mo, contre 16 Mo pour celui associé aux quatre cœurs Zen 5.

Ces différences ne rendent pas les Zen 5c inutiles.

Ils permettent d'augmenter le nombre total de cœurs dans une enveloppe matérielle contrainte.

Mais pour une tâche sensible à la fréquence maximale et à la taille du cache, l'exécuter sur un Zen 5 plutôt que sur un Zen 5c peut apporter un avantage important.

Encore faut-il que le système d'exploitation prenne cette décision au bon moment.

Quand une optimisation du cache devient contre-productive

La régression concerne une fonction appelée Cache Aware Scheduling.

Son principe consiste à tenir compte de la topologie des caches du processeur pour répartir les tâches.

Lorsqu'un programme s'exécute sur un cœur CPU, certaines données peuvent être conservées dans différents niveaux de cache.

Si ce programme est déplacé vers un cœur ne partageant pas le même domaine de cache, une partie de ces données doit parfois être récupérée à nouveau.

Cette opération peut ajouter de la latence et augmenter les accès à la mémoire.

Il est donc généralement intéressant d'éviter les migrations inutiles.

Cache Aware Scheduling cherche notamment à améliorer cette localité.

Le problème apparaît lorsque le coût d'un déplacement devient inférieur au gain que l'on pourrait obtenir en exécutant la tâche sur un cœur plus rapide.

Sur le Ryzen AI 9 HX 370, l'ordonnanceur pouvait maintenir un travail exigeant sur un groupe de Zen 5c uniquement pour préserver sa proximité avec un cache existant.

Pendant ce temps, des cœurs Zen 5 plus performants pouvaient rester disponibles.

Une optimisation pertinente dans un contexte pouvait ainsi provoquer une régression dans un autre.

Une compilation Clang particulièrement pénalisée

Le problème a été signalé initialement par Klaus Kusche, utilisateur de Gentoo Linux.

Il a observé un ralentissement lors de travaux de compilation utilisant LLVM Clang et une optimisation globale du programme à l'édition des liens.

Cette technique, appelée Link-Time Optimization ou LTO, permet au compilateur d'analyser différentes parties d'un programme lors de sa construction finale.

Elle peut améliorer les performances du logiciel produit, mais demande parfois beaucoup de ressources au moment de la compilation.

Les opérations full-LTO constituent un cas particulièrement exigeant.

Elles peuvent utiliser beaucoup de mémoire, solliciter fortement les caches et monopoliser un cœur durant une période prolongée.

Sur la machine examinée, ces tâches pouvaient démarrer sur les cœurs Zen 5c et y rester malgré la disponibilité de cœurs plus rapides.

Les différences de fréquence et de cache se cumulaient alors.

L'utilisateur constatait une dégradation importante des temps de compilation par rapport à des versions du noyau ne présentant pas ce comportement.

Il s'agit d'un scénario reproductible décrit dans les échanges techniques, pas d'une démonstration selon laquelle tous les programmes Linux subissaient le même ralentissement.

Deux stratégies de placement qui ne donnaient pas la même réponse

Pour comprendre le correctif, il faut distinguer deux mécanismes de l'ordonnanceur Linux.

Le premier est Cache Aware Scheduling.

Il cherche à éviter les déplacements défavorables entre domaines de cache, notamment lorsque plusieurs tâches bénéficient d'une bonne localité mémoire.

Le second est asymmetric packing.

Ce mécanisme prend en compte une hiérarchie entre les processeurs disponibles et cherche à privilégier les cœurs jugés plus performants.

Sur une machine utilisant des cœurs de capacités différentes, les deux stratégies ne conduisent pas toujours au même emplacement.

Cache Aware Scheduling peut recommander de conserver une tâche sur son groupe de cœurs actuel.

Asymmetric packing peut au contraire préférer la déplacer vers un cœur plus rapide.

La régression venait du fait que la politique de localité du cache pouvait bloquer cette seconde décision.

L'ordonnanceur privilégiait alors une économie potentielle d'accès mémoire au détriment d'un gain plus important en puissance de calcul.

Le correctif donne la priorité aux cœurs les plus performants

Le développeur Tim Chen a proposé une modification de cette logique.

Lorsque asymmetric packing identifie un cœur inactif de priorité supérieure, la politique de localité du cache ne doit plus systématiquement empêcher le déplacement.

Dans cette situation, l'avantage procuré par un cœur plus rapide doit pouvoir l'emporter sur le coût éventuel d'une migration entre domaines de cache.

Le correctif modifie les décisions prises lors de l'équilibrage de charge régulier et actif.

Il agit donc directement sur les conditions dans lesquelles une tâche est autorisée à migrer.

L'objectif n'est pas de déplacer toutes les tâches vers les Zen 5.

Il consiste à empêcher qu'une règle de localité bloque un déplacement pertinent lorsque des ressources plus performantes sont disponibles.

Cette approche conserve les avantages de Cache Aware Scheduling dans les situations où ils restent appropriés.

C'est une correction ciblée d'un conflit de priorités, pas l'abandon d'une optimisation entière.

Le problème n'était pas limité à une mauvaise fréquence CPU

L'écart entre 3,3 et 5,1 GHz peut donner l'impression que le bug concernait simplement la gestion de la fréquence des cœurs.

En réalité, il s'agit d'un problème différent.

Le système ne forçait pas nécessairement un cœur Zen 5 rapide à fonctionner à une fréquence anormalement basse.

Il pouvait choisir de laisser la tâche sur un autre cœur, dont les caractéristiques matérielles étaient moins favorables à cette charge.

La distinction est importante pour le diagnostic.

Un gouverneur de fréquence CPU et un ordonnanceur ne remplissent pas les mêmes fonctions.

Le premier intervient dans le choix des états de fréquence et de consommation.

Le second décide quel travail doit être exécuté et sur quel processeur logique.

Changer de gouverneur d'énergie ne constitue donc pas automatiquement une correction à ce type de problème de placement.

Le correctif intégré à Linux agit sur la décision d'ordonnancement elle-même.

Pourquoi ce correctif concerne particulièrement les développeurs

La compilation de logiciels constitue un bon révélateur des problèmes d'ordonnancement.

Certaines phases peuvent exploiter de nombreux cœurs en parallèle.

D'autres dépendent davantage de la vitesse d'exécution d'un nombre limité de tâches.

Lorsque le programme utilise intensivement le cache, un placement défavorable peut pénaliser plusieurs caractéristiques à la fois.

Un développeur utilisant fréquemment Clang, de grandes bibliothèques ou des projets compilés avec LTO peut donc être particulièrement sensible à cette régression.

Sur une distribution comme Gentoo, où une partie importante du logiciel peut être compilée localement, ces charges sont relativement courantes.

Cela explique pourquoi un utilisateur de cette distribution a pu identifier le problème lors de son utilisation quotidienne.

Cependant, tous les projets logiciels n'utilisent pas la même stratégie de compilation.

Le correctif ne garantit pas que les temps de construction de chaque programme diminueront.

Il traite une situation précise dans laquelle les décisions de placement étaient incorrectes.

Un développeur Intel contribue à corriger une plateforme AMD

Un aspect intéressant de cette affaire concerne l'origine du correctif.

La modification a été proposée par Tim Chen, ingénieur Intel impliqué dans le développement du noyau Linux.

Elle répond à une régression documentée sur un processeur AMD.

Ce type de collaboration est courant dans les projets open source.

L'ordonnanceur est une infrastructure commune qui doit fonctionner correctement sur de nombreuses familles de processeurs.

Une amélioration apportée pour un cas précis peut également bénéficier à des architectures partageant certaines caractéristiques.

Le travail a fait l'objet d'échanges avec d'autres contributeurs, dont Klaus Kusche, auteur du signalement initial.

Les discussions ont permis de tester différentes versions du correctif et d'adapter le code à des branches plus anciennes.

Cette méthode de développement ne dépend pas uniquement des relations commerciales entre constructeurs.

Elle repose sur la possibilité d'examiner publiquement les modifications et de les tester sur du matériel réel.

Le correctif sera aussi destiné aux branches Linux 7.2 et 7.3

La modification a été intégrée dans le développement de Linux 7.4 à travers les correctifs de l'ordonnanceur.

Phoronix rapporte également qu'elle est marquée pour être rétroportée vers les branches stables Linux 7.2 et 7.3.

Le rétroportage consiste à adapter une correction à une version antérieure du noyau.

Cette démarche permet à des utilisateurs de bénéficier d'une réparation sans nécessairement migrer vers la version principale la plus récente.

Elle est particulièrement importante pour les distributions privilégiant la stabilité.

Les discussions techniques montrent d'ailleurs que l'adaptation à Linux 7.2 nécessite certains changements par rapport au code plus récent.

La présence d'un correctif dans Linux 7.4 ne garantit donc pas que l'on puisse appliquer exactement le même fichier à une ancienne version.

Les interfaces internes de l'ordonnanceur peuvent évoluer.

Les équipes chargées des branches stables doivent vérifier que la modification fonctionne avec leur base de code.

À la date de l'actualité, l'intention de rétroportage est documentée. Sa disponibilité effective dépendra des prochaines publications.

Tous les Ryzen AI ne sont pas nécessairement affectés

Le signalement concerne précisément le Ryzen AI 9 HX 370.

Phoronix estime que d'autres processeurs mélangeant des cœurs Zen 5 et Zen 5c pourraient également bénéficier du correctif.

Cette possibilité est cohérente avec le fonctionnement général de l'ordonnanceur.

Mais elle ne doit pas être transformée en liste officielle d'appareils défectueux.

Le comportement dépend de la topologie du processeur, des caractéristiques des domaines de cache, de la version du noyau et du type de charge exécutée.

Deux ordinateurs utilisant des processeurs proches peuvent présenter des résultats différents selon leur configuration logicielle.

Un portable Ryzen AI ne devient donc pas automatiquement moins performant simplement parce qu'il utilise Linux.

Il faut que les conditions déclenchant la régression soient réunies.

Les mesures réalisées sur la charge de compilation initiale ne permettent pas de conclure que tous les logiciels étaient affectés.

Quels gains de performances peut-on attendre ?

C'est probablement la question la plus importante pour les utilisateurs.

Les sources techniques décrivent une dégradation importante sur les compilations Clang full-LTO examinées.

Elles ne fournissent cependant pas de pourcentage universel permettant de promettre un gain précis sur toutes les machines.

L'effet dépend de l'utilisation du cache, de la durée des tâches et de la disponibilité des cœurs.

Une charge qui reste déjà sur les cœurs les plus appropriés ne bénéficiera pas nécessairement de la modification.

De même, une application qui utilise efficacement plusieurs cœurs sans rencontrer ce conflit de placement peut afficher des performances inchangées.

Il serait donc trompeur d'affirmer que Linux 7.4 rend tous les ordinateurs AMD plus rapides.

La correction vise un ralentissement provoqué par une décision incorrecte de l'ordonnanceur.

Elle ne constitue pas une augmentation intrinsèque de la puissance du processeur.

Les jeux vidéo peuvent-ils aussi en bénéficier ?

Un correctif touchant l'ordonnanceur intéresse naturellement les joueurs.

Sur certaines architectures hybrides, le placement des tâches peut influencer les performances d'un jeu, notamment lorsque certaines portions du code utilisent intensivement le CPU.

Cependant, le problème étudié ici a été documenté sur une charge de compilation particulièrement exigeante.

Les échanges techniques ne démontrent pas un gain généralisé du nombre d'images par seconde dans les jeux.

Il n'est donc pas possible d'annoncer une amélioration chiffrée des performances gaming.

Les jeux présentent des comportements très variés.

Certains dépendent principalement de la carte graphique, d'autres sollicitent davantage quelques threads CPU.

La répartition des tâches, la gestion du cache et les limites thermiques jouent aussi un rôle.

Des benchmarks réalisés après l'intégration du correctif seraient nécessaires pour mesurer son impact réel sur différents titres.

Faut-il changer immédiatement de noyau Linux ?

Pour un utilisateur qui ne rencontre aucun ralentissement particulier, aucune urgence spécifique ne découle de cette actualité.

Le correctif suit le processus habituel d'intégration et de maintenance du noyau.

Les distributions mettront progressivement à disposition les versions correspondantes selon leurs propres calendriers.

Un utilisateur de Gentoo ou d'une distribution à mises à jour rapides pourra éventuellement recevoir la modification avant quelqu'un utilisant une distribution entreprise à cycle plus long.

Cela ne signifie pas que les distributions plus conservatrices ignoreront le problème.

Elles peuvent intégrer un correctif rétroporté sans modifier le numéro de version principale du noyau.

Avant de changer de noyau, il est préférable de vérifier la version réellement utilisée et la présence du correctif dans les notes de maintenance.

Installer manuellement une version expérimentale peut introduire d'autres risques de stabilité ou de compatibilité.

Pour les développeurs confrontés à la régression, le suivi des publications stables et des correctifs distribués officiellement constitue une approche plus raisonnable.

Une petite modification pour un problème de fond

Cette correction illustre une difficulté croissante de l'informatique moderne.

Les processeurs disposent de plus en plus de ressources hétérogènes.

Le système d'exploitation doit tenir compte à la fois des performances des cœurs, de la localisation des données, de la consommation énergétique et de la répartition de la charge.

Il n'existe pas une règle de placement qui soit optimale dans toutes les situations.

Conserver une tâche près de son cache peut être avantageux.

La déplacer vers un cœur plus rapide peut l'être davantage lorsque l'écart de performances compense les coûts de migration.

C'est précisément cet arbitrage que le correctif de Tim Chen vient améliorer.

Le Ryzen AI 9 HX 370 ne manque pas de ressources matérielles. Dans le scénario signalé, Linux ne les mobilisait simplement pas au meilleur endroit.

L'intégration de cette correction dans Linux 7.4, avec des rétroportages prévus, constitue donc une amélioration concrète pour les configurations concernées.

Elle rappelle surtout qu'un bon ordonnanceur doit savoir quand préserver la localité du cache et quand accepter de déplacer une tâche pour utiliser un cœur nettement plus performant.