Rafael Wysocki a proposé un correctif qui change la façon dont intel_pstate dialogue avec les processeurs Intel dotés du Dynamic Efficiency Control, la fonction de gestion d'énergie qui arrive avec les Core Ultra Series 3 Panther Lake. Aujourd'hui, le pilote écrit une valeur de performance désirée dans MSR_HWP_REQUEST. Sur une puce compatible DEC, Wysocki estime que cela risque d'embrouiller le micrologiciel du processeur : le correctif met donc ce champ à zéro et laisse le micrologiciel choisir lui-même le point de fonctionnement. Le patch vise la fenêtre de fusion de Linux 7.3 et n'est accompagné d'aucun chiffre, ce qu'il faut dire clairement.
The short answer
Rafael Wysocki a proposé un correctif qui fait mettre à zéro par intel_pstate le champ de performance désirée de MSR_HWP_REQUEST sur les processeurs dotés du Dynamic Efficiency Control, la fonction qui arrive avec les Core Ultra Series 3 Panther Lake. Son raisonnement : écrire une cible précise risque d'embrouiller le micrologiciel du processeur, alors que la laisser à zéro permet à ce dernier de déterminer lui-même le niveau adapté. Le correctif vise Linux 7.3, sans mesures.
Vingt ans de travail sur la fréquence des processeurs sous Linux peuvent se résumer ainsi : le noyau reconnaît progressivement qu'il n'est pas le bon endroit pour prendre cette décision. Voici une étape de plus.
Rafael Wysocki, qui maintient la partie gestion d'énergie du noyau, a proposé un correctif modifiant le comportement d'intel_pstate sur les processeurs compatibles Dynamic Efficiency Control. DEC est une fonction destinée aux charges légères, qui arrive avec les Core Ultra Series 3, la génération Panther Lake. Le changement est bref et précis : sur une puce compatible DEC, le pilote écrira zéro dans le champ de performance désirée de MSR_HWP_REQUEST au lieu d'une cible calculée.
La raison avancée par Wysocki est qu'écrire une valeur à cet endroit risque d'embrouiller le micrologiciel du processeur, et que fixer la préférence à zéro laisse ce micrologiciel déterminer lui-même le niveau de performance le plus adapté.
Le réglage auquel le noyau renonce
Il vaut la peine d'être précis sur le réglage concerné, parce que HWP en compte plusieurs et qu'ils ne font pas le même travail.
Quand le noyau s'adresse à un processeur en Hardware P-States, il écrit un registre de requête qui porte un minimum, un maximum, une préférence entre énergie et performance, et une valeur désirée. Les trois premiers sont des contraintes, des bornes à l'intérieur desquelles le processeur reste libre. Le champ désiré n'est pas une borne. C'est une consigne, et l'écrire réduit la liberté du processeur à un point unique.
Zéro dans ce champ est la façon définie de refuser d'avoir un avis. Le processeur prend les contraintes et choisit le point de fonctionnement. Sur une puce dont le micrologiciel applique sa propre logique d'efficacité, c'est l'arrangement le plus susceptible de produire ce que ce micrologiciel était censé produire.
Ce que ce correctif ne nous dit pas
Aucun chiffre de performance ou de consommation n'accompagne le correctif. Cela nous semble assez important pour être dit deux fois, parce que la tentation, avec un changement pareil, est de le présenter comme un gain d'autonomie et de laisser le lecteur supposer qu'un chiffre existe.
Le cadrage du correctif est celui de la justesse. Le noyau envoyait quelque chose qui pouvait embrouiller le micrologiciel, il va cesser. Un micrologiciel non embrouillé se comporte en général mieux, donc le sens attendu est favorable. Un sens attendu n'est pas une mesure, et sur les puces mobiles modernes le résultat dépend énormément de la charge de travail, des limites de puissance de la plateforme et de ce que le constructeur a fait du micrologiciel.
Ajoutons que le correctif était en relecture pour la fenêtre de fusion de 7.3, pas confirmé dedans. À ce stade les correctifs passent en général, et parfois non.
Qui doit s'en soucier maintenant
Presque personne, et c'est très bien ainsi.
Si vous exploitez du matériel Panther Lake sous Linux, l'action utile consiste à noter votre noyau actuel et à réexaminer le comportement énergétique une fois passé en 7.3 ou plus récent, puisque le pilote agira différemment sous vos pieds. Mesurer avant et après sur votre propre charge de travail vaut mieux que n'importe quelle affirmation générale, y compris la nôtre.
Si vous exploitez du matériel plus ancien, ce correctif ne touche pas vos machines. Les réglages de fréquence dont vous disposiez la semaine dernière sont ceux dont vous disposez aujourd'hui.
Le point plus large mérite d'être emporté. Sur les puces mobiles Intel, l'équilibre du contrôle glisse vers le processeur depuis des années, et chacun de ces correctifs déplace un peu plus la décision hors du noyau. C'est plutôt bon pour la consommation, et plutôt frustrant pour qui veut comprendre pourquoi une machine a choisi telle fréquence, puisque le raisonnement se déroule de plus en plus dans un micrologiciel que personne hors d'Intel ne peut lire.
Sources et pour aller plus loin
- Linux to avoid confusing processor firmware with newer Intel CPUs sporting DEC, Phoronix, août 2026
- Le pilote intel_pstate, documentation du noyau
- CPU performance scaling, documentation du noyau
- Archives de la liste linux-pm
Questions fréquentes
Qu'est-ce que le champ de performance désirée dans MSR_HWP_REQUEST ?
Les Hardware P-States, ou HWP, déplacent le choix de la fréquence du système d'exploitation vers le processeur. Le noyau cesse de désigner des fréquences précises et écrit à la place un registre de requête décrivant ce qu'il souhaite : un plancher de performance, un plafond, une préférence entre énergie et performance, et une valeur désirée. Les trois premiers sont des contraintes. Le champ désiré est différent, parce qu'il fixe une cible précise plutôt qu'une borne, et l'écrire reprend une part de l'autonomie que HWP était censé donner au processeur. Le laisser à zéro est la manière documentée de dire que l'on n'a pas d'avis et que le processeur décide, ce que fait exactement ce correctif sur les puces compatibles DEC.
Qu'est-ce que le Dynamic Efficiency Control ?
C'est une fonction récente de gestion d'énergie chez Intel, orientée charges légères, qui arrive avec les Core Ultra Series 3, la génération Panther Lake. En résumé, le micrologiciel du processeur prend des décisions plus fines sur la manière de traiter efficacement de petites quantités de travail, plutôt que de foncer vers une fréquence élevée puis de redescendre. La documentation technique publique reste maigre et nous n'allons pas prétendre le contraire. Ce que le correctif nous apprend est d'ordre comportemental : le micrologiciel raisonne suffisamment de son côté pour qu'une cible précise venue du noyau puisse le contrarier au lieu de l'aider.
Dois-je changer quelque chose sur mes machines ?
Non. Il s'agit d'un changement côté noyau, actif uniquement sur du matériel qui annonce le support DEC, et il ne demande aucune configuration. Si vous faites tourner du Panther Lake sous Linux, le geste utile est de noter votre version de noyau actuelle et de réexaminer le comportement énergétique après le passage en 7.3 ou plus récent, puisque c'est à ce moment que le pilote changera de conduite sous vos pieds. Sur tout matériel plus ancien, ce correctif ne touche à rien. La gestion de fréquence chez Intel garde exactement les mêmes réglages que la semaine dernière.
Mon portable va-t-il consommer moins ?
On l'ignore, et personne n'a publié de chiffre. Le correctif est présenté comme une correction de justesse plutôt que comme une optimisation : il empêche le noyau d'envoyer un signal susceptible d'embrouiller le micrologiciel, et un micrologiciel qui n'est pas embrouillé se comporte en général mieux qu'un micrologiciel qui l'est. C'est une attente raisonnable, pas une mesure. Si l'autonomie sur Panther Lake compte pour vous, le conseil honnête est de mesurer votre propre charge de travail de part et d'autre du changement de noyau plutôt que de supposer un sens, parce que sur les puces modernes le résultat énergétique dépend énormément de ce que la machine fait réellement.
Comment observer ce que fait ma machine côté fréquence aujourd'hui ?
Commencez par identifier le pilote aux commandes, car la réponse conditionne tout le reste. Lisez scaling_driver dans le répertoire cpufreq de sysfs. S'il indique intel_pstate, vous êtes bien sur le pilote que ce correctif modifie, et la préférence énergie/performance exposée à cet endroit est le réglage qui a le plus d'effet réel sur la plupart des systèmes. S'il indique acpi-cpufreq, vous êtes sur un chemin tout autre. Au-delà, turbostat est l'outil qui montre ce qui s'est réellement passé plutôt que ce qui a été demandé, et c'est cette distinction qui compte dès lors que le micrologiciel décide.