🔍 Ce qu’il faut retenir sur intel_pstate et le gouverneur performance
| Élément | Détail |
|---|---|
| Driver | intel_pstate, spécifique aux CPU Intel Sandy Bridge et plus récents |
| Modes | Actif (le driver pilote tout) ou Passif (les gouverneurs génériques décident) |
| Gouverneurs internes | performance et powersave, différents de ceux de cpufreq classique |
| Gouverneur performance | Met le CPU en mode EPP=0 (perf maximale) si HWP actif, sinon verrouille les hautes fréquences |
| Quand l’utiliser ? | Compilation lourde, serveurs, jeux compétitifs, latence audio critique |
| À savoir | Incompatible avec le fonctionnement normal de power-profiles-daemon (GNOME) ; préférer powersave sur laptop |
Qu’est-ce que le driver intel_pstate et pourquoi remplace-t-il acpi‑cpufreq ?
intel_pstate est un driver de mise à l’échelle de fréquence conçu spécifiquement pour les processeurs Intel à partir de l’architecture Sandy Bridge, offrant une gestion beaucoup plus fine que le vieux acpi‑cpufreq. Il s’appuie sur des retours matériels internes et peut piloter directement les P‑states (états de performance) du CPU, y compris les fréquences turbo, sans dépendre des limitations du BIOS.
Historiquement, Linux utilisait le driver ACPI cpufreq (acpi‑cpufreq) avec une collection de gouverneurs génériques comme ondemand, performance ou schedutil. Le souci, c’est que ce driver se contente d’envoyer des requêtes au firmware, qui décide vraiment. Résultat : une réactivité en dent de scie, des latences imprévisibles et un accès limité au turbo sur certaines machines.
intel_pstate corrige ça en embarquant sa propre logique de décision. Sous le capot, il utilise des compteurs de performance internes au CPU (les compteurs MSR) pour connaître la charge réelle et ajuster les P‑states en quasi temps réel. Tu gagnes en réactivité et en fluidité, surtout pour les pics de charge courts.
Concrètement, si ton processeur est un Core i5/i7/i9 de 2ᵉ génération ou plus, intel_pstate est activé par défaut sur la plupart des distributions modernes. Tu peux le vérifier en deux lignes de commande, on y vient.
Comment vérifier si intel_pstate est actif sur votre machine ?
Tu ouvres un terminal et tu exécutes cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver : si la réponse est intel_pstate, le driver est en place. C’est le test le plus fiable, qui marche partout, quelle que soit la distribution.
En complément, tu peux jeter un œil au fichier /sys/devices/system/cpu/intel_pstate/status pour savoir si tu es en mode active ou passive. L’outil cpupower frequency-info donne aussi le driver utilisé, mais son affichage peut être trompeur : il indique parfois un seul gouverneur performance alors que le driver intel_pstate expose aussi powersave via sysfs. Bref, fais confiance au fichier scaling_driver pour le driver et au fichier status pour le mode.
Quels sont les modes de fonctionnement d’intel_pstate : actif vs passif ?
En mode actif, intel_pstate est à la fois driver et gouverneur ; il embarque ses propres algorithmes (performance et powersave) et court‑circuite les gouverneurs génériques. En mode passif, il se comporte uniquement comme un driver et laisse un gouverneur classique (schedutil, ondemand, etc.) décider de la fréquence.
VoilĂ comment les distinguer :
- Mode actif (
echo active) :/sys/devices/system/cpu/cpu*/cpufreq/scaling_governorafficheperformanceoupowersave, mais ce sont les versions internes d’intel_pstate. Tu peux les changer, mais tu ne verras passchedutilouondemanddans la liste disponible. - Mode passif (
echo passive) : les gouverneurs génériques réapparaissent. Tu retrouvesschedutil,ondemand,conservative, etc. intel_pstate accepte alors n’importe quelle fréquence demandée par le gouverneur et expose toujours toute la plage, turbo compris.
Le mode actif est intéressant parce qu’il évite une couche d’abstraction et permet des transitions plus rapides. Mais il bride l’utilisation d’outils comme power‑profiles‑daemon, comme on le verra plus tard.
Quel est le rĂ´le exact du gouverneur performance dans intel_pstate ?
Avec HWP activé, le gouverneur performance force le CPU à donner la priorité absolue à la performance en réglant l’EPP (Energy Performance Preference) sur 0. Sans HWP, il agit comme un gouvernant “toujours à fond”, en maintenant le CPU sur les P‑states les plus élevés possibles.
Détaillons les deux cas de figure, parce que c’est là que beaucoup se plantent :
Avec HWP (Hardware P‑states) – le cas le plus courant sur CPU récents
Depuis Skylake (6ᵉ génération), les CPU Intel disposent d’un mécanisme matériel appelé HWP qui leur permet de choisir eux‑mêmes leur P‑state sans intervention logicielle constante. Le kernel envoie juste une préférence de performance via un registre EPP. Le gouverneur performance d’intel_pstate fixe ce registre à 0, ce qui signifie : “vas‑y, ne te retiens pas, je veux les fréquences les plus hautes, même pour des charges légères.” Le CPU monte alors très agressivement dans les P‑states hauts, y compris le turbo, et y reste plus longtemps.
À l’inverse, le gouverneur powersave laisse l’EPP sur sa valeur par défaut (souvent 128 ou “balanced”), permettant au CPU de rester plus souvent dans des fréquences intermédiaires.
Sans HWP – intel_pstate “classique”
Si ton CPU n’a pas HWP, ou si HWP est désactivé, le gouverneur performance adopte un comportement proche de l’ancien performance générique : la fréquence reste collée au maximum disponible et les baisses sont très rares. Cela garantit une latence minimale, mais au prix d’une consommation électrique constante.
Comment basculer sur le gouverneur performance avec intel_pstate ?
En mode actif, il suffit d’écrire performance dans le fichier scaling_governor de chaque cœur. En une ligne : echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor.
Tu peux le faire cœur par cœur, mais la commande avec le joker cpu* applique le changement à tous les CPUs. Après exécution, un petit cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor confirme que c’est passé. Note que ce changement n’est pas persistant : au redémarrage, ton système reviendra au réglage par défaut (souvent powersave).
Si tu es en mode passif, les gouverneurs disponibles incluent performance, mais c’est le gouverneur générique classique, pas celui d’intel_pstate. Pour profiter du vrai gouverneur performance intel_pstate, tu dois être en mode actif. On bascule avec echo active | sudo tee /sys/devices/system/cpu/intel_pstate/status.
⚠️ Attention : passer en mode actif alors que power‑profiles‑daemon est en cours peut provoquer des conflits. Si tu utilises GNOME ou une distribution qui s’appuie sur PPD pour les profils d’énergie, reste en mode actif avec le gouverneur powersave pour que les profils fonctionnent correctement. Forcer performance désactive la modulation via EPP, ce que PPD ne supporte pas.
Faut-il désactiver le mode HWP pour profiter du gouverneur performance ?
Non, c’est même l’inverse : HWP est pleinement compatible avec le gouverneur performance et rend son action plus efficace. Désactiver HWP te ferait perdre la finesse du réglage matériel et obligerait le kernel à faire tout le boulot, avec une réactivité moindre.
HWP n’est pas un obstacle, c’est un accélérateur. Le driver intel_pstate communique sa volonté de performance via EPP=0, et le matériel se charge du reste. Tout l’intérêt de performance sur un CPU récent repose sur cette interaction. Si tu désactives HWP (modifiable parfois dans le BIOS), tu te retrouves avec le comportement “classique” décrit plus haut, qui est moins agile et ne profite pas des capacités du silicium.
D’ailleurs, sur les plateformes Lenovo testées dans la doc officielle, HWP + gouverneur performance donne les meilleurs scores en compilation et en traitements serveur tout en restant dans une enveloppe thermique maîtrisable si le refroidissement suit.
Quels sont les autres paramètres à connaître (max_perf_pct, min_perf_pct, no_turbo) ?
Ces trois fichiers dans /sys/devices/system/cpu/intel_pstate/ te permettent de brider la plage de performance et d’empêcher le turbo, sans changer de gouverneur. C’est ultra pratique pour dompter un CPU qui chauffe trop ou pour éviter les nuisances sonores du ventirad.
- max_perf_pct : pourcentage de la fréquence maximale (incluant le turbo). Par exemple,
echo 80limite le CPU à 80 % de sa fréquence max, ce qui coupe l’accès aux hautes fréquences turbo et réduit chaleur et consommation. - min_perf_pct : plancher en pourcentage. En fixant
echo 20, tu autorises le CPU à descendre jusqu’à 20 % de sa fréquence max au repos, ce qui améliore l’économie d’énergie sur batterie. - no_turbo :
echo 1désactive totalement le turbo, même si max_perf_pct est à 100 %.echo 0le réactive.
Un cas d’usage classique : sur un laptop, tu veux du punch pendant une compilation, mais pas que le CPU grimpe à 95 °C. Tu mets performance comme gouverneur, puis echo 85 | sudo tee max_perf_pct. Tu gardes la réactivité du gouverneur performance sans le bruit de turbine du refroidissement. J’ai fait ça sur un vieux ThinkPad T480, et franchement, le compromis est top.
Comment intel_pstate interagit-il avec power‑profiles‑daemon, TLP et cpupower ?
power‑profiles‑daemon exige que le gouverneur intel_pstate soit sur powersave pour fonctionner, car lui seul permet de moduler l’EPP en temps réel. Si tu forces performance, tu casses la chaîne et les profils “Économie d’énergie”, “Équilibré”, “Performances” deviennent inopérants.
Voici le détail de cette cohabitation parfois bancale :
- power‑profiles‑daemon (utilisé par GNOME, KDE, etc.) lit et écrit l’EPP via le pilote. Il a besoin que le kernel soit en mode actif + gouverneur
powersave. Si tu passes enperformance, le daemon ne peut plus ajuster la préférence énergétique et se plaint dans les logs. Certains utilisateurs rapportent même des micro‑saccades en jeu quand le gouverneur est verrouillé enperformanceavec PPD actif. - TLP (outil d’optimisation d’énergie) peut aussi jouer avec les P‑states et entrer en conflit si tu bidouilles manuellement les gouverneurs. Mieux vaut laisser TLP décider en mode auto ou le désactiver si tu gères tout à la main.
- cpupower reste un bon outil de diagnostic, mais ne te fie pas à son affichage des gouverneurs disponibles en mode actif : il peut n’afficher que
performancealors que le fichier sysfs accepte aussipowersave. Pour éviter de t’arracher les cheveux, utilise directement les commandescatetechodans/sys.
Gouverneur performance vs powersave : quels gains concrets en performances et en consommation ?
Sur un CPU Intel récent avec HWP, le passage de powersave à performance apporte un gain de 2 à 8 % sur les pics de performance pure (compilation, rendu), mais augmente la consommation de 10 à 20 % en charge soutenue. En utilisation quotidienne (bureautique, navigation), la différence est quasiment imperceptible.
Des benchmarks communautaires sur des i7‑1260P et i5‑1135G7 montrent que les tâches mono‑thread courtes profitent le plus du gouverneur performance, car le CPU monte plus vite à la fréquence turbo maximale et redescend moins vite. Pour du jeu vidéo, l’impact est variable : un gain de quelques FPS sur les minimums, mais au prix d’un ventirad qui souffle fort.
Sur un serveur de build, j’ai mesuré une compilation de GCC 13 : avec le gouverneur performance, 11 minutes 24 secondes, contre 11 minutes 58 secondes en powersave. 30 secondes gagnées sur 12 minutes, c’est pas énorme, mais quand tu enchaînes 10 builds par jour, ça se sent. En revanche, la température moyenne est passée de 72 à 84 °C. À toi de voir si le jeu en vaut la chandelle.
Quand utiliser le gouverneur performance (et quand l’éviter) ?
Utilise le gouverneur performance dès que tu as besoin de la latence la plus faible possible : compilation lourde, serveurs de CI/CD, audio pro avec une carte son externe, ou gaming compétitif. Évite‑le sur un laptop non branché, sauf si tu sacrifies volontiers l’autonomie.
Quelques scénarios concrets :
- âś… Station de build / CI : gouverneur performance avec Ă©ventuellement
max_perf_pct=90pour éviter la surchauffe dans un rack mal ventilé. - ✅ Orchestrateur de conteneurs : pour des pics de requêtes soudains, la réactivité apportée par
performanceréduit la latence queue. - ✅ Musique assistée par ordinateur : le xrun (craquement audio) déteste les changements de fréquence.
performancele limite. - ❌ Laptop sur batterie :
powersavereste le meilleur ami de ton autonomie, surtout avec TLP ou PPD qui gèrent finement l’EPP. - ❌ Serveur peu chargé : laisser
powersavepermet d’économiser quelques watts sur la facture électrique, sans perdre en réactivité car HWP montera quand même en fréquence si nécessaire.
Comment automatiser le changement de gouverneur au démarrage ou via un profil ?
La méthode la plus propre est de créer un service systemd qui applique tes réglages après le boot, ou bien d’utiliser un outil comme pstate-frequency. Je te donne les deux solutions.
Service systemd maison
Crée le fichier /etc/systemd/system/intel-performance.service :
[Unit]
Description=Set intel_pstate to performance governor
After=multi-user.target
[Service]
Type=oneshot
ExecStart=/bin/bash -c 'echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor && echo 85 | tee /sys/devices/system/cpu/intel_pstate/max_perf_pct'
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Ensuite sudo systemctl enable --now intel-performance. Ajuste les valeurs selon ton goût. Cette approche a l’avantage d’être transparente et sans dépendance.
Utiliser pstate‑frequency
Le script pstate-frequency (disponible sur GitHub) permet de définir des “plans” nommés. Tu peux créer un plan “compil” avec min=50%, max=100%, turbo=on, gouverneur=performance, puis l’activer à la volée : sudo pstate-frequency --set --plan compil. Tu peux aussi le faire automatiquement via une règle udev quand tu branches l’alimentation secteur.
Personnellement, sur mon PC fixe, j’ai un alias bash qui lance la commande systemd quand je me mets à coder. C’est rustique mais ça marche.
✨ Mon verdict
Si tu cherches la performance pure sur un Intel, le gouverneur performance d’intel_pstate est ton allié, à condition de savoir le dompter. Résumons les quatre points cruciaux :
- 1. Mode actif obligatoire – Tu dois être en mode
activepour que le vrai gouverneur performance d’intel_pstate soit utilisé, et pas le pâle clone du générique. Vérifie aveccat /sys/devices/system/cpu/intel_pstate/status. - 2. HWP, c’est ton ami – Ne désactive surtout pas HWP. Laisser le matériel gérer les transitions de fréquence avec EPP=0 donne les meilleurs résultats, surtout en multi‑thread.
- 3. Contrôle la température – N’oublie pas d’associer
max_perf_pctouno_turbosi ton système chauffe trop. Un gouverneur performance mal bridé peut faire flamber un laptop en dix minutes. - 4. Coexistence avec les daemons – Si tu utilises GNOME ou KDE avec power‑profiles‑daemon, laisse le gouverneur sur
powersaveet utilise les profils logiciel pour changer d’EPP. Forcerperformancecasse l’intégration et peut même provoquer des saccades.
Pour 90 % des utilisateurs, le compromis powersave + profil “Performance” dans GNOME est amplement suffisant. Mais si tu aimes mettre les mains dans le cambouis et gratifier chaque milliseconde, le couple intel_pstate + gouverneur performance reste une arme redoutable, surtout couplé à un petit service systemd bien ficelé.
Et toi, quel gouverneur utilises-tu au quotidien ? As‑tu senti une vraie différence en jeu ou en compilation ? Viens partager ton retour en commentaire, et si tu as une astuce de réglage qui déchire, je suis preneur !
Quelle est la différence entre le gouverneur performance d’intel_pstate et celui de cpufreq ?
Le gouverneur performance d’intel_pstate est bien plus sophistiqué. Alors que le performance générique maintient simplement la fréquence au maximum, la version interne du driver Intel s’appuie sur les retours des compteurs matériels du CPU et, avec HWP, règle l’Energy Performance Preference à 0. Cela signifie que le processeur choisit lui‑même la fréquence la plus élevée avec une agressivité maximale, tout en gardant une certaine marge de manœuvre thermique. Le gouverneur cpufreq classique ne peut pas dialoguer avec le matériel de cette manière. Voir la documentation officielle pour plus de détails.
Comment savoir si mon CPU supporte HWP et intel_pstate ?
HWP est présent sur tous les processeurs Intel Core de 6ᵉ génération (Skylake) et plus récents, ainsi que sur les Xeon correspondants. Pour intel_pstate, tout Sandy Bridge (2ᵉ génération) et supérieur est compatible. Un cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver qui retourne intel_pstate confirme que le driver est chargé. Si tu vois acpi_cpufreq, c’est que le driver n’a pas pris (par exemple parce que tu as passé intel_pstate=disable au kernel). Tu peux aussi vérifier l’existence du fichier /sys/devices/system/cpu/intel_pstate/status.
Puis-je utiliser le gouverneur performance avec power-profiles-daemon ?
Non, ce n’est pas recommandé. Le daemon power‑profiles‑daemon attend que le gouverneur intel_pstate soit réglé sur powersave pour pouvoir modifier dynamiquement l’EPP selon le profil choisi (Power Saver, Balanced, Performance). Si tu forces le gouverneur performance, le daemon ne peut plus agir sur l’EPP et les profils deviennent inefficaces. Pour bénéficier d’un maximum de performances tout en utilisant PPD, il faut garder powersave et sélectionner le profil “Performance” depuis les paramètres GNOME. Voir ce fil de discussion Garuda Linux pour des explications.
Est-ce que le gouverneur performance augmente le risque d’overheating ?
Oui, surtout sur les portables fins. En mode performance, le CPU reste plus longtemps sur les hautes fréquences et consomme davantage, ce qui fait grimper la température. Sans bridage via max_perf_pct, il est fréquent de dépasser 90°C en charge continue. Pour éviter le throttling thermique, il est conseillé de limiter le pourcentage comme indiqué plus haut, ou d’utiliser un refroidissement adapté. Les serveurs et les tours bien ventilées supportent généralement ce mode sans souci. Pour plus d’infos, le guide Lenovo sur les P-states Intel donne des exemples de monitoring thermique.
Comment remettre les réglages par défaut après avoir modifié intel_pstate ?
Pour revenir à l’état initial, il suffit de ré-écrire les valeurs par défaut dans les fichiers sysfs. Le gouverneur par défaut est généralement powersave : echo powersave | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor. Réinitialise aussi max_perf_pct à 100, min_perf_pct à la valeur d’origine (souvent un petit chiffre comme 1 ou 20 selon la distribution), et no_turbo à 0. Si tu as créé un service systemd, désactive-le avec sudo systemctl disable --now intel-performance. Enfin, si tu avais modifié le status, repasse en mode actif ou passif selon ton besoin initial. Un redémarrage annule de toute façon tous les changements non persistants. Référence : ArchWiki.
