SysadminNews

Linux fige en dur les fréquences Zen 6, faute de mieux

Sur cette page
  1. Ce que CPPC donne au noyau, et ce qu'il a cessé de donner
  2. C'est la capacité qui casse
  3. Trois types de cœurs, et un premier chiffre pour le nouveau
  4. Des fréquences plutôt que des valeurs de performance abstraites
  5. À quoi s'attendre, et quand
  6. Sources et pour aller plus loin

Une série de correctifs publiée sur la liste du noyau Linux le 1er septembre 2026 fait ce que le noyau évite d'ordinaire : elle inscrit trois fréquences de processeur directement dans le code source. Les puces Zen 6 client utilisent l'ACPI CPPC autrement que les plateformes AMD précédentes, et l'ordonnanceur a besoin de la fréquence maximale de chaque type de cœur pour calculer la capacité. L'ACPI n'offre pas encore d'interface pour la lire. Donc en attendant qu'une révision de la spécification en ajoute une, le noyau porte des valeurs figées de 5025 pour les cœurs performance, 3524 pour les cœurs efficacité et 2399 pour le nouveau type de cœur basse consommation. C'est ce dernier chiffre qui intéresse, car c'est le premier repère public sur un type de cœur qu'AMD n'a pas encore livré.

The short answer

AMD a publié le 1er septembre 2026 des correctifs Linux ajustant la gestion de l'ACPI CPPC pour les processeurs Zen 6 client. Ces puces utilisent CPPC autrement que les plateformes AMD précédentes, et le noyau a besoin d'une fréquence maximale par type de cœur pour calculer la capacité de l'ordonnanceur. L'ACPI ne l'expose pas encore, donc les correctifs figent 5025 pour les cœurs performance, 3524 pour les cœurs efficacité et 2399 pour un nouveau type basse consommation, appliqués à tous les Zen 6 client de la série Model 80. Le cœur basse consommation se situe donc à 0,68 fois le cœur efficacité et 0,47 fois le cœur performance. Pour Zen 6 et au-delà, le rapport de boost se calcule aussi depuis des fréquences plutôt que depuis l'échelle abstraite CPPC. Trop tard pour 7.3, donc Linux 7.4 au plus tôt.

5025valeur figée du cœur performance
2399nouveau type de cœur basse conso
7.4noyau le plus tôt possible
Carte réponse expliquant les correctifs CPPC pour Zen 6 : le noyau fige des fréquences maximales de 5025, 3524 et 2399 pour les cœurs performance, efficacité et basse consommation, faute d'une interface ACPI capable de les rapporter.
Trois nombres dans un fichier source, à la place d'une interface ACPI qui n'existe pas encore. PNG

Les développeurs du noyau ne mettent pas de constantes magiques dans les fichiers sources s'ils peuvent l'éviter. Quand il en apparaît une, c'est en général le bord visible d'un écart entre ce que fait le matériel et ce qu'une norme a eu le temps de décrire. Une série de correctifs publiée le 1er septembre 2026 en ajoute trois, et le raisonnement qui les accompagne est une petite visite guidée du fonctionnement réel de l'ordonnancement processeur.

Ce que CPPC donne au noyau, et ce qu'il a cessé de donner

CPPC est le mécanisme ACPI par lequel un système d'exploitation et une plateforme négocient la fréquence et la mise à l'échelle énergétique du processeur. Plutôt que de nommer une fréquence en mégahertz, le système exprime ses demandes sur une échelle de performance abstraite, et la plateforme décide de ce qu'elle en fait. Cette abstraction est le but recherché. Elle permet à une seule interface noyau de fonctionner chez des constructeurs aux comportements de fréquence très différents, et elle laisse le micrologiciel appliquer des contraintes thermiques et énergétiques que le système ne voit pas.

Les puces AMD prennent CPPC en charge depuis des années. Les processeurs Zen 6 client, d'après la série de correctifs, l'utilisent autrement que les plateformes précédentes, et cette différence a une conséquence : le noyau ne peut plus déduire la fréquence maximale d'un type de cœur donné à partir de ce que CPPC rapporte.

Cela ressemble à un détail jusqu'à ce qu'on se demande à quoi servait ce nombre.

C'est la capacité qui casse

Sur un processeur hétérogène, un ordonnanceur a besoin d'une échelle commune pour comparer les types de cœurs. Pas leurs fréquences en tant que telles, mais leur capacité relative à abattre du travail, afin de répondre à des questions comme : déplacer cette tâche d'un petit cœur vers un grand aidera-t-il assez pour justifier la migration, ou cette file d'exécution est-elle surchargée au regard de ce que ce cœur précis peut fournir.

Cette échelle s'appelle la capacité, et elle dérive de la performance de crête de chaque type de cœur. Trompez-vous et tout ce qui est bâti dessus hérite de l'erreur. L'équilibrage de charge place le travail au mauvais endroit. Les gouverneurs de fréquence se trompent sur le taux de charge d'un cœur. Le placement conscient de l'énergie, qui raisonne explicitement sur la performance par watt entre types de cœurs, produit des absurdités bien assurées.

Le texte de présentation du correctif pose le problème simplement : les plateformes Zen 6 client utilisent CPPC différemment des plateformes précédentes, et connaître la fréquence maximale d'un type de cœur est nécessaire aux calculs de capacité. De nouvelles versions de l'ACPI introduiront une interface propre pour obtenir cette information, mais en attendant les valeurs sont figées pour que les systèmes se comportent comme prévu et pour débloquer le travail à venir sur l'ordonnanceur.

Relisez la dernière proposition, car c'est la partie honnête. Quelqu'un tente d'écrire la prise en charge de l'ordonnanceur pour du matériel qui arrivera que l'organisme de normalisation ait fini ou non, et il lui faut un nombre contre lequel travailler.

Graphique comparant les valeurs d'échelle de fréquence figées pour Zen 6 client : cœurs performance à 5025, cœurs efficacité à 3524 et nouveau type basse consommation à 2399.
Les trois valeurs telles qu'elles apparaissent dans les correctifs. Des rapports, pas des promesses sur le silicium livré. PNG

Trois types de cœurs, et un premier chiffre pour le nouveau

Les valeurs figées placent les cœurs performance Zen 6 à 5025, les cœurs efficacité Zen 6 à 3524, et le nouveau type basse consommation à 2399.

C'est la troisième entrée qui mérite qu'on s'y arrête. Les puces AMD grand public ont deux types de cœurs depuis que Zen 4c a introduit les cœurs denses : des cœurs performance complets et des cœurs efficacité qui échangent fréquence et surface contre densité. Zen 6 ajoute un troisième étage sous les deux, et ce correctif est l'endroit où un chiffre public apparaît pour la première fois.

En rapport, le cœur basse consommation vaut 0,68 fois le cœur efficacité et 0,47 fois le cœur performance complet. En gros, il tourne à un peu moins de la moitié d'un cœur performance.

Viennent maintenant les réserves, qui comptent autant que les nombres. Il s'agit d'un jeu figé unique appliqué à tous les Zen 6 client de la série Model 80, et rien n'indique avec quel soin il a été ajusté. C'est une valeur d'échelle de fréquence, pas une spécification. Et surtout, on n'apprend rien ici sur la consommation réelle de ces cœurs basse consommation, seul chiffre qui dirait à quoi ils servent. Un cœur à 0,47 fois la fréquence n'a aucun intérêt s'il consomme 0,47 fois l'énergie. Il en a beaucoup s'il n'en consomme qu'une fraction.

Notre couverture précédente de l'extension d'amd_hsmp aux puces Zen 6 client suit l'autre moitié de ce travail préparatoire, et nos notes sur l'équilibrage entre grappes hybrides dans Linux 7.3 décrivent ce que fait l'ordonnanceur avec des topologies hétérogènes côté Intel.

Des fréquences plutôt que des valeurs de performance abstraites

La série contient un second changement à signaler. Pour Zen 6 et au-delà, le rapport de boost est calculé à partir de valeurs de fréquence plutôt que depuis l'échelle arbitraire de valeurs de performance CPPC.

C'est un changement d'approche, pas un simple détail d'implémentation. L'échelle de performance CPPC est délibérément sans unité. Son contrat tient essentiellement au fait que plus grand signifie plus rapide, sans promettre que les nombres correspondent à quoi que ce soit de mesurable. Excellent pour la portabilité, inutile quand il faut raisonner sur combien plus rapide.

Faire reposer le calcul du rapport de boost sur de vraies fréquences donne au noyau du concret. Cela crée aussi une dépendance à des fréquences fiables, précisément la dépendance que les valeurs figées viennent combler. Les deux moitiés de cette série sont la même décision vue de deux côtés : le noyau veut raisonner en unités physiques, et l'interface qui fournirait ces unités n'est pas encore livrée.

À quoi s'attendre, et quand

Les correctifs sont arrivés trop tard pour Linux 7.3, dont la fenêtre de fusion est fermée. Leur intégration la plus précoce possible est Linux 7.4.

C'est une version à marquer. Linux 7.4 s'annonce comme la version importante pour la prise en charge des Ryzen de nouvelle génération, et elle pourrait sortir fin décembre 2026, ce qui la placerait en position de devenir le noyau à support long terme de l'année. Les noyaux LTS sont ceux sur lesquels les distributions d'entreprise s'appuient et qui restent déployés des années, donc beaucoup de machines Zen 6 rencontreront Linux pour la première fois via 7.4 ou l'un de ses dérivés.

Si vous préparez des déploiements Zen 6 client, deux conséquences. D'abord, 7.4 est la version à suivre, et tout ce qui précède ne saura pas quoi faire du troisième type de cœur. Ensuite, les chiffres de capacité sur ces machines seront d'abord des approximations et non des valeurs remontées par le micrologiciel, ce qui mérite d'être gardé en tête si le placement de l'ordonnanceur sur du Zen 6 précoce se révèle étrange d'une façon que personne n'explique immédiatement.

Les constantes figées dans le noyau ont une fâcheuse tendance à survivre à la situation qui les justifiait. Celle-ci a un chemin de remplacement clair et une raison énoncée. Reste à savoir si l'interface ACPI arrivera avant ou après le matériel, et cela, personne ne le maîtrise.

Sources et pour aller plus loin

Questions fréquentes

Pourquoi le noyau a-t-il besoin d'une fréquence maximale par type de cœur ?

Pour les calculs de capacité. Quand un ordonnanceur place du travail sur un processeur hétérogène, il lui faut une échelle commune pour comparer ce que peuvent faire des cœurs différents, sinon il ne peut pas raisonner sur l'intérêt de déplacer une tâche d'un type de cœur vers un autre. Cette échelle dérive de la performance de crête relative de chaque type de cœur. Sur les plateformes AMD précédentes, le noyau obtenait ce qu'il lui fallait via l'échelle de valeurs de performance CPPC existante. Les puces Zen 6 client utilisent CPPC autrement, et les nombres lisibles ne permettent plus de retrouver les maxima par type de cœur. Sans ces nombres, la capacité est fausse, et tout ce que l'ordonnanceur construit dessus l'est aussi.

Pourquoi figer en dur plutôt que lire les valeurs depuis le micrologiciel ?

Parce qu'il n'y a actuellement nulle part où les lire. L'auteur des correctifs le dit explicitement : de nouvelles versions de la spécification ACPI introduiront une interface propre pour obtenir la fréquence maximale d'un type de cœur, et les valeurs figées existent pour que ces machines se comportent comme prévu et pour débloquer le travail à venir sur l'ordonnanceur pendant l'attente. C'est un arbitrage raisonnable. L'alternative consiste soit à livrer des valeurs de capacité connues comme fausses, soit à bloquer le développement de l'ordonnanceur sur du matériel qui arrivera de toute façon. Ces valeurs seront remplacées par celles remontées par le micrologiciel dès que la norme aura rattrapé son retard.

Que nous disent réellement les trois nombres sur Zen 6 ?

Que les puces AMD grand public passent de deux à trois types de cœurs. Les cœurs performance sont figés à 5025, les cœurs efficacité ou denses à 3524, et un nouveau type basse consommation à 2399. En rapport, le cœur basse consommation se situe à 0,68 fois le cœur efficacité et 0,47 fois le cœur performance complet. Prenez cela comme des indications d'échelle approximatives plutôt que comme des spécifications produit : le correctif applique un seul jeu figé à tous les Zen 6 client de la série Model 80, et rien n'indique avec quel soin ces valeurs ont été ajustées. Rien non plus ici sur la consommation réelle de ces cœurs basse consommation, qui serait pourtant le chiffre révélant leur raison d'être.

Qu'est-ce qui change d'autre dans le calcul du rapport de boost ?

Pour Zen 6 et au-delà, le rapport de boost est calculé à partir de valeurs de fréquence plutôt que depuis l'échelle arbitraire de valeurs de performance CPPC. C'est un changement d'approche notable. L'échelle de performance CPPC est délibérément abstraite : une plage sans unité dont la seule exigence est la monotonie, ce qui la rend portable entre constructeurs mais inutile pour raisonner sur quoi que ce soit qu'un humain reconnaîtrait comme de la vitesse. Dériver le rapport de boost de vraies fréquences donne au noyau du concret, au prix d'un besoin de fréquences fiables, ce qui est exactement le problème que les valeurs figées viennent masquer.

Quand cela arrive-t-il, et cela me concerne-t-il aujourd'hui ?

Cela ne vous concerne pas aujourd'hui, sauf si vous travaillez sur le code d'ordonnancement ou de gestion d'énergie du noyau. Les correctifs sont arrivés trop tard pour Linux 7.3, donc leur intégration la plus précoce possible est Linux 7.4. Cette version est attendue vers fin décembre 2026 et se présente comme candidate au noyau à support long terme de l'année, ce qui en ferait la base sur laquelle la plupart des distributions d'entreprise s'appuieront. Si vous préparez des déploiements Zen 6 client, retenez que 7.4 est la version à surveiller, et que les premiers chiffres de capacité sur ces machines seront des approximations et non la vérité du micrologiciel.