Une série de correctifs postée sur la liste de diffusion du noyau Linux ajoute une option nommée epp_boost au pilote amd_pstate, et le résultat mesuré est l'un des meilleurs que nous ayons vus pour un réglage d'ordonnancement. Sur un Valve Steam Deck lançant le benchmark Civilization VI, les images 1 % low progressent de 31,8 % et le temps d'image p99 de 4,1 %. Le mécanisme tient en peu de choses : échantillonner l'activité de chaque cœur au plus toutes les 10 ms, et si un cœur est occupé à au moins la moitié, figer sa préférence énergie performance sur performance jusqu'à ce que 300 ms passent sans nouvelle activité. Rien n'est encore fusionné, et le profil de charge concerné ne se limite pas au jeu.
The short answer
David Vernet, ingénieur noyau Linux chez Meta, a posté des correctifs ajoutant une option epp_boost au pilote amd_pstate. Activée avec amd_pstate.epp_boost=1, elle échantillonne la résidence C0 de chaque cœur au plus toutes les 10 ms, place la préférence énergie performance de ce cœur sur performance quand l'échantillon le montre occupé à au moins 50 %, et restaure la demande précédente après 300 ms sans nouvel échantillon actif. Sur un Valve Steam Deck, le benchmark Civilization VI gagne 31,8 % sur les images 1 % low et 4,1 % sur le temps d'image p99. La série est en relecture et n'a pas été fusionnée.
La plupart des correctifs de gestion de fréquence arrivent avec un chiffre à un seul chiffre et une longue discussion pour savoir si ce chiffre est réel. Celui ci arrive avec 31,8 %, le genre de valeur qui pousse à vérifier ce qui a été mesuré avant de s'y intéresser.
Le problème, c'est un thread occupé qui fait des siestes
Le dispositif par défaut sur le matériel AMD récent confie beaucoup d'autorité au processeur. Le pilote amd_pstate du noyau, en mode actif, ne choisit pas directement une fréquence. Il transmet au matériel une indication, la préférence énergie performance, et le matériel décide. Ce partage des rôles est délibéré et fonctionne en général bien, car le silicium réagit plus vite que n'importe quelle boucle noyau.
Il fonctionne moins bien pour un profil de charge précis. David Vernet, ingénieur noyau chez Meta, le décrit dans sa lettre d'accompagnement : une charge dominée par un thread majoritairement occupé qui prend de fréquentes siestes courtes s'accommode mal de cette stratégie. Le thread travaille vraiment, bloque un instant, se réveille et doit être rapide immédiatement. Une préférence équilibrée voit les siestes et se calme. Le temps qu'elle soit remontée, l'image, ou la requête, est déjà en retard.
Les jeux tombent là dedans en permanence, ce qui explique que le benchmark soit un jeu. Beaucoup de logiciels sans rapport avec le graphisme aussi.
Ce que le correctif y change
Le mécanisme est volontairement modeste. Vous l'activez avec le paramètre noyau amd_pstate.epp_boost=1 et un hook update util commence à échantillonner. Pour chaque cœur, il lit la résidence C0, la part de temps passée à exécuter du code plutôt qu'à rester inactif, au plus une fois toutes les 10 ms. Si un échantillon revient avec le cœur occupé à au moins 50 %, le pilote écrit performance dans le champ EPP de ce cœur. Le boost est ensuite maintenu jusqu'à ce que 300 ms passent sans nouvel échantillon actif, moment où la demande précédente est remise en place.
C'est toute l'idée. Elle s'applique par cœur et non globalement, ce qui la distingue du simple fait de placer chaque CPU sur performance en acceptant la facture énergétique. Les cœurs réellement inactifs restent sur une politique équilibrée. Les cœurs qui portent le thread occupé sont maintenus en haut, y compris pendant les courtes siestes qui les feraient sinon redescendre.
Lire les deux chiffres
Le benchmark Civilization VI sur un Steam Deck gagne 31,8 % sur les images 1 % low. Le temps d'image p99 gagne 4,1 %.
Les deux valeurs viennent du même essai, et l'écart entre elles est instructif plutôt que contradictoire. Les 1 % low sont le centième le plus mauvais des images, celles qui ont le plus de chances d'être tombées sur un cœur tout juste réveillé à basse fréquence. C'est précisément la population que le boost cherche à sauver, donc un gain important à cet endroit et un gain modéré au quatre vingt dix neuvième centile est ce à quoi un mécanisme qui fonctionne doit ressembler. Un correctif qui déplacerait tous les centiles de la même valeur serait plus suspect, pas moins.
La réserve est la réserve habituelle. Un jeu, une console portable, du silicium Van Gogh. Personne n'a publié de charge serveur, de compilation ou de session de bureau mesurée de la même façon.
Ce que nous vérifierions avant de nous en soucier
Si vous exploitez du matériel AMD et que les pics de latence sont une plainte réelle, trois choses méritent d'être connues avant que ce correctif n'approche de vos machines.
D'abord, dans quel mode de pilote vous êtes réellement. amd_pstate propose les modes actif, guidé et passif, et l'indication EPP n'existe que dans le premier. Lire /sys/devices/system/cpu/amd_pstate/status vous situe.
Ensuite, quelle est votre préférence actuelle. Chaque CPU expose energy_performance_preference sous /sys/devices/system/cpu/cpuN/cpufreq/, avec les valeurs acceptées listées à côté dans energy_performance_available_preferences. Si la vôtre indique déjà performance partout, ce correctif n'a rien à vous apporter et vous en payez déjà la facture énergétique.
Enfin, si votre problème a la bonne forme. Le boost aide un thread qui alterne entre activité et courtes inactivités. Il ne fait rien pour un thread saturé en continu, car celui là maintient déjà la fréquence haute tout seul.
État d'avancement
La série est sur la liste de diffusion du noyau et en relecture. Elle n'est pas fusionnée, aucune version cible n'a été annoncée, et les hooks par cœur qui s'exécutent toutes les 10 ms attirent en général des questions minutieuses sur leur surcoût avant d'aller quelque part. Voyez y une proposition accompagnée d'un benchmark inhabituellement bon, et revenez y quand un mainteneur se sera prononcé.
Sources et pour aller plus loin
- Phoronix : les correctifs AMD P-State peuvent améliorer les 1 % low de 31 %
- Steam Deck HQ : de nouveaux correctifs Linux améliorent les 1 % low du Steam Deck de 31 %
- tbreak : le correctif AMD P-State vise un jeu plus fluide sur Steam Deck
- Documentation du noyau : pilote de mise à l'échelle amd-pstate
- Documentation du noyau : intel_pstate et la préférence énergie performance
Questions fréquentes
Qu'est ce que l'EPP, et pourquoi cela compte il pour la latence ?
EPP signifie energy performance preference, préférence énergie performance. C'est une indication que le système d'exploitation transmet au contrôleur matériel du processeur, pour lui dire jusqu'où pencher vers la performance ou vers l'économie d'énergie quand il choisit une fréquence. Sur les machines AMD utilisant amd_pstate en mode actif, la valeur se trouve dans un fichier sysfs par CPU et accepte des noms comme performance, balance_performance, balance_power et power. Le matériel garde la décision finale, ce qui est tout l'intérêt de la conception, mais l'indication change son empressement à monter en fréquence. Quand elle reste sur une position équilibrée, un cœur qui sort d'une courte sieste passe du temps à regrimper vers une fréquence utile, et c'est exactement cette remontée qu'une charge sensible à la latence ressent.
Que changent concrètement les correctifs proposés ?
Ils ajoutent un paramètre de module, amd_pstate.epp_boost, qui active une boucle d'échantillonnage par cœur. Un hook update util lit la résidence C0 de chaque cœur, c'est à dire la fraction de temps passée à exécuter du code plutôt qu'à rester inactif, au plus une fois toutes les 10 ms. Si un échantillon montre le cœur occupé à au moins 50 %, le pilote écrit performance dans le champ EPP de ce cœur. Il maintient ensuite ce réglage jusqu'à ce que 300 ms s'écoulent sans nouvel échantillon actif, moment où la demande précédente est restaurée. Rien d'autre ne change dans la sélection de fréquence. C'est une réponse ciblée à un seul mode de défaillance, pas un nouveau gouverneur.
Les chiffres du benchmark viennent ils d'une charge réelle ?
Ils viennent du benchmark Civilization VI exécuté sur un Valve Steam Deck, qui repose sur le silicium Van Gogh d'AMD. Le chiffre principal est une amélioration de 31,8 % des images 1 % low, avec un temps d'image p99 en hausse de 4,1 %. L'écart entre ces deux valeurs mérite une lecture attentive. Les 1 % low décrivent le centième le plus mauvais des images, là où une remontée lente en fréquence se voit le plus nettement, donc un gain important à cet endroit et un gain plus modeste au p99 est cohérent avec le mécanisme annoncé. Cela reste un jeu, sur une console portable, à traiter comme un signal fort et non comme un chiffre général.
Est ce que cela ne sert qu'au jeu ?
Le jeu est l'endroit où la mesure a été faite, pas la limite du phénomène. Le développeur décrit le cas problématique comme une charge dominée par un thread majoritairement occupé qui prend de fréquentes siestes courtes. Cette description convient aussi à une session shell interactive, à un gestionnaire de requêtes qui bloque brièvement sur une socket ou un disque, à un système de compilation en attente d'un sous processus, et à une bonne partie des logiciels de bureau. Tous peuvent tomber dans le même piège : assez occupés pour avoir besoin d'une fréquence élevée, assez souvent inactifs pour qu'une politique équilibrée les fasse redescendre. Reste à savoir si le gain est du même ordre ailleurs, et personne n'a publié de chiffres là dessus.
Puis je en profiter aujourd'hui sans recompiler un noyau ?
En partie. Vous ne pouvez pas obtenir le boost automatique par cœur, puisque c'est le code nouveau. Vous pouvez en revanche inspecter et modifier vous même l'indication EPP dès maintenant sur une machine utilisant amd_pstate en mode actif, en lisant et en écrivant le fichier energy_performance_preference sous chaque CPU dans sysfs. Le passer à performance partout est la version brutale de ce que fait le correctif de façon sélective, et cela vous coûte de la consommation au repos sur tous les cœurs plutôt que sur les seuls cœurs occupés. Sur une station de travail branchée au secteur, ce compromis passe souvent. Sur une console portable sur batterie, c'est précisément le compromis que la série de correctifs cherche à éviter.