Ne pas oublier de faire les mises à jours systèmes (voir les mises à jours de updates-testing) et de le relancer avant de faire quoi que ce soit!

Hello,

Je ne sais pas si tous le monde avait cette astuce, mais j'ai activé le pstate AMD sur mon Ryzen 7 5800x sur carte mère X470 au lieu du cpu-frequency plus fait pour les Intel :
https://www.kernel.org/doc/html/latest/admin-guide/pm/amd-pstate.html

Du coup je passe d'une gestion avec :
2.2Ghz de base -> 4,85Ghz
 cpupower frequency-info
analyse du CPU 0 :
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  limitation matérielle : 2.20 GHz - 4.85 GHz
  available frequency steps:  3.80 GHz, 2.80 GHz, 2.20 GHz
  régulateurs disponibles : conservative ondemand userspace powersave performance schedutil
  tactique actuelle : la fréquence doit être comprise entre 2.20 GHz et 3.80 GHz.
                  Le régulateur "schedutil" est libre de choisir la vitesse
                  dans cette plage de fréquences.
  current CPU frequency: 2.20 GHz (asserted by call to hardware)
  boost state support:
    Supported: yes
    Active: yes
    Boost States: 0
    Total States: 3
    Pstate-P0:  3800MHz
    Pstate-P1:  2800MHz
    Pstate-P2:  2200MHz
A une gestion de :
550Mhz -> 4,85Ghz
 cpupower frequency-info
analyse du CPU 0 :
  driver: amd-pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 131 us
  limitation matérielle : 550 MHz - 4.85 GHz
  régulateurs disponibles : conservative ondemand userspace powersave performance schedutil
  tactique actuelle : la fréquence doit être comprise entre 550 MHz et 4.85 GHz.
                  Le régulateur "schedutil" est libre de choisir la vitesse
                  dans cette plage de fréquences.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 3.00 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    AMD PSTATE Highest Performance: 166. Maximum Frequency: 4.85 GHz.
    AMD PSTATE Nominal Performance: 130. Nominal Frequency: 3.80 GHz.
    AMD PSTATE Lowest Non-linear Performance: 60. Lowest Non-linear Frequency: 1.75 GHz.
    AMD PSTATE Lowest Performance: 19. Lowest Frequency: 550 MHz.

Il suffit de modifier le fichier /etc/default/grub comme suit :

GRUB_CMDLINE_LINUX="amd_pstate.shared_mem=1 rhgb quiet"
[s]GRUB_CMDLINE_LINUX="amd_pstate=passive rhgb quiet"[/s]
et de relancer la génération du grub (Exemple en UEFI, sinon voir la doc : https://doc.fedora-fr.org/wiki/GRUB2_:_Les_bases_pour_Fedora ) :
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Du coup cela abaisse encore plus la consommation et gère bien plus finement la vitesse du processeur 🙂.

Il faut que votre dmesg retourne les informations suivante :
dmesg | grep pstat
[    0.999164] amd_pstate: This processor supports shared memory solution, you can enable it with amd_pstate.shared_mem=1
Cela devrait aussi permettre de changer d'état plus rapidement qu'avec la gestion en CPU Frequency.
https://www.phoronix.com/review/amd-pstate-linux517

A voir pour les générations plus anciennes des Ryzen.
A savoir que Amd Pstate est disponible à partir des Ryzen 3xxx (ZEN2).

Après quelques tests, je gagne 50Mhz de moyenne sur tous les threads lors des empaquetages/compilation passant de 4500Mhz à 4550/4575Mhz constant.

Sur un cœur je passe de 4775Mhz de moyenne à 4825Mhz (réglage bios tout en "AUTO"). Pour un cpu donné au max à 4,7Ghz sur un coeur c'est pas si mal 🙂 sans avoir fait quoi que ce soit. Et sur chipset x470 🙂 .

Reste à voir si le mode "powersave" à 550Mhz, sur tous les threads, est exploitable en utilisation normal (navigation/bureautique).

Dommage que la carte graphique RX5700XT ne consomme pas au repo aussi peu que la RX6500XT. Sachant que la première consomme en moyenne 11Watts alors que la seconde est à 3Watts.

Donc n'hésitez pas à en faire de même chez vous 🙂 .
Et avec l'outil graphique "corectrl" (dispo dans les dépôts, pour le processeur et la carte graphique), c'est simple de passer d'un mode de fonctionnement à l'autre et donc de faire des économies d'énergie.

A savoir que cette dernière partie est aussi valable pour les possesseurs d'intel 😉 , mais aussi NVIDIA...
Merci pour ce retour et toutes ces informations.

Ça vaudrait peut-être le coup de l'intégrer dans des articles de la Documentation mais j'ai l'impression que ça va demander beaucoup de reprise d'articles qui présentent sûrement des choses obsolètes.
Voir compiler sur une doc dédié aux améliorations qui ne sont pas active par défaut.

J'ai testé sur F36 et F37, a savoir que cela vas s'améliorer avec les prochaines versions du noyau et sans doute que l'on aura peut être un support des anciennes génération de ZEN (ZEN1/Ryzen 1xxx, ZEN1+/Ryzen 2xxx). Mais à voir la génération de pstate est différente...

Cela est surtout bénéfique pour les processeurs de PC portable (Bon là j'ai pas toutes les références en tête... Surtout qu'il y a souvent du mélange de génération... Donc normalement si pas de cœurs processeur ZEN2, pas de "Collaborative Processor Performance Control (CPPC)"/amd_pstate pour le moment...).
Voir aussi les NAS ou les machines qui ne demandent pas à être à pleine puissance tout le temps 🙂 .
VINDICATORs wrote:Voir compiler sur une doc dédié aux améliorations qui ne sont pas active par défaut.

J'ai testé sur F36 et F37, a savoir que cela vas s'améliorer avec les prochaines versions du noyau et sans doute que l'on aura peut être un support des anciennes génération de ZEN (ZEN1/Ryzen 1xxx, ZEN1+/Ryzen 2xxx). Mais à voir la génération de pstate est différente...

Cela est surtout bénéfique pour les processeurs de PC portable (Bon là j'ai pas toutes les références en tête... Surtout qu'il y a souvent du mélange de génération... Donc normalement si pas de cœurs processeur ZEN2, pas de "Collaborative Processor Performance Control (CPPC)"/amd_pstate pour le moment...).
Voir aussi les NAS ou les machines qui ne demandent pas à être à pleine puissance tout le temps 🙂 .
C'est quand même dommage que cette activation ne soit pas prise en compte automatiquement lors de l'installation de l'OS par la reconnaissance du matériel... On va bientôt avoir des machines sous architecture ZEN4.
Après est ce simple à mettre par défaut ou non? Considéré comme très stable?

Et il y a encore pas mal de travail dessus. Mais bon a première vu les bénéfices semblent plus important. A voir à la longue en utilisation, là je suis a distance dessus et les tests de stress n'ont pas apportés de problème.
Juste des température inférieur malgré une vitesse d'horloge plus importante et qui semble plus stable.
Après c'est peut être aussi dût aux température plus fraiche de ces derniers jours...

En stress test avec le mode "powersave" pas de souci non plus, mais 16*550MHz,faudra pas trop en demander 🙂
VINDICATORs wrote:Après est ce simple à mettre par défaut ou non? Considéré comme très stable?

Et il y a encore pas mal de travail dessus. Mais bon a première vu les bénéfices semblent plus important. A voir à la longue en utilisation, là je suis a distance dessus et les tests de stress n'ont pas apportés de problème.
Juste des température inférieur malgré une vitesse d'horloge plus importante et qui semble plus stable.
Après c'est peut être aussi dût aux température plus fraiche de ces derniers jours...
Non ça n'a pas l'air d'être encore très stable, d'ailleurs c'est indiqué dans l'article que tu as joins, mais c'est justement ça que je voulais dire, je trouve ça dommage, c'est quand même quelque chose qui est extrêmement à la base du fonctionnement d'un système.
GOGI wrote:
VINDICATORs wrote:Après est ce simple à mettre par défaut ou non? Considéré comme très stable?

Et il y a encore pas mal de travail dessus. Mais bon a première vu les bénéfices semblent plus important. A voir à la longue en utilisation, là je suis a distance dessus et les tests de stress n'ont pas apportés de problème.
Juste des température inférieur malgré une vitesse d'horloge plus importante et qui semble plus stable.
Après c'est peut être aussi dût aux température plus fraiche de ces derniers jours...
Non ça n'a pas l'air d'être encore très stable, d'ailleurs c'est indiqué dans l'article que tu as joins, mais c'est justement ça que je voulais dire, je trouve ça dommage, c'est quand même quelque chose qui est extrêmement à la base du fonctionnement d'un système.
Si des problèmes de stabilité sont remontés, il est logique que ce ne soit pas par défaut. Il faut certainement un peu plus de maturité pour que les devs l’intègrent d'office.
Après il y a un nombre incalculable des paramètres/options possible qui ne sont pas toujours disponible/réglé, etc...
Donc il est possible que cela sera le cas ici, surtout si personne ne pense à rajouter une script de détection lors de l'installation...

J'ai fais un peu le tour du net pour trouver de la doc en français sur le sujet, mais mes recherches ne donnent pas grand chose. L'équivalent à Phoronix en langue de molière n'est pas pour demain...

Après niveau bogues il y en a bien plus sur des techno/appli dite stable.
Là que deux rapports sur le bugzilla par exemple :
https://bugzilla.redhat.com/buglist.cgi?quicksearch=amd_pstate

A voir sur celui du noyau.

Édit :

Bah même sur le bugzilla du noyau c'est un peu la mort coté rapport de bogue :

https://bugzilla.kernel.org/buglist.cgi?no_redirect=0&quicksearch=amd_pstate

Et pas grand chose qui semble être lié...

Niveau dev noyau ce n'est pas non plus grand chose : https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?qt=grep&q=amd_pstate
Par contre faut 186 minutes pour empaqueter les différentes versions de la bibliothèque graphique Mesa-Git au lieu de 23 minutes à fond (16x4,5Ghz)... ou +/-43 minutes max avec cpu-frequency en "powersave" (16x2,2Ghz).
real    186m18,871s
user    2359m43,436s
sys     142m44,162s
Et 31°C de température pour 19°C dans l'air...

A voir l'incidence sur le relevé de consommation électrique du jour. Si mon compteur linky se mette enfin à renvoyer les bonnes informations du jour un jour... (ils m'ont fait sier pour me le changer car il y avait un souci dessus, mais au final je pense qu'ils l'ont jamais fait... du coup plus de retour d'info depuis des mois...)
Et même test en performance 🙂 :
real    27m30,354s
user    330m41,564s
sys     21m9,956s
Avec 72°C de température processeur.
Bon comme je suis passe à Fedora 37, je déplacerai ce sujet dessus.

Plus qu'un souci avec l’activation du mode "secure boot" sur les VM+l'hibernation + la mise en veille, et ce sera parfait 🙂 .

A savoir que amd_pstate s'améliore encore avec les prochaines versions du noyau. A voir si ces reportés ou non.

A voir l'incidence sur la consommation électrique... je sent que je vais me trouver un testeur à la prise pour surveiller ce point là. Vu que le changement de mon compteur linky soit disant effectué n'a jamais été fait à première vue... et comme il retourne rien du tout... c'est beau la "modernité"... j'ai jamais changé de compteur (sauf pour lors de l'installation initial des lignes) avant et là... paf!

Pour en revenir à nos moutons, sachez que même en 16x550Mhz le système reste utilisable (visualisation vidéo, écoute audio, bureautique) sans problème (bon après j'ai le reste qui suit... A voir l'impact avec rien que des unités de stockage type Disque dur "HDD").
J'ai réglé l'outil "CoreCtrl" avec des profils selon l'application utilisé (exemple : en mode "économie d'énergie" sur le profil par défaut et un profil en mode "performance" pour steam, ainsi que les jeux) et cela fonctionne très bien.
Par contre certaines actions restent plus lente (exemple lors des mises à jours, certains "scriptlet" prennent plus de temps à s’exécuter), mais bon... c'est quand même acceptable.
un mois plus tard
Après quelques semaines de tests, il en ressort que le meilleur choix pour ne pas être trop limité est de ne pas rester sur le mode "powersave" (économie d'énergie), mais sur le "conservative" (conservateur).

On oscille entre 550Mhz et 1,3Ghz selon la charge (cela peut monter un peu plus haut, mais c'est rare).

Le "powersave" force à rester sur 550Mhz et c'est vite trop lent en utilisation.
Le "conservative" permet de ne pas ressentir un fort ralentissement dès que l'on fais autre chose (comme passer en plein écran lors du visionnage d'une vidéo). Cela tout en étant aussi économe.

Pour CORECTRL, j'ai trouvé une astuce pour pouvoir le gérer en espace utilisateur, je la mettrais ici plus tard.

Reste à voir pour en faire une doc 🙂 .
Merci pour ces tests et retours.

Pas de souci pour te faire la relecture de la future documentation 😉
5 jours plus tard
VINDICATORs,
Merci pour cette enquête/explication.
Mais les tests de Phoronix ne semblent pas être très concluant...
Cela évolue avec le temps.

Mais bon le but c'est surtout de pouvoir faire baisser la consommation de son processeur quand il est peu utilisé.
Amd_pstate est plus complet par rapport à cpufreq plus adapté à intel. Mais évolue au fur et à mesure des sorties du noyau (c'est encore mieux avec le 6.1, mais pas mieux que ce qui est prévu d'ici le 6.3...).

Après tu as la vitesse entre les changements de fréquence qui est bien mieux géré.

Mais bon c'est clair que tu ne vas pas vraiment gagner en perf. En conso cela baisse bien, mais là aussi la différence ne vas pas être de "2,21 Gigo Watts en moins" comme dirait le professeur Emmett Brown ...

Après les tests présenté dans le lien de phoronix sont pour le noyau 5.17, à voir si il y en a eu d'autres depuis avec des noyaux/patchs plus récents
https://www.phoronix.com/search/amd-pstate
Ce lien parle de tout les articles qui en parlent du plus récent au plus anciens.
Encore plus précis :
https://www.phoronix.com/search/P-State
De nouveau avec le drivers Nvidia et amd-pstate.

Après avoir initier amd-paste avant l'installation du driver nvidia, celui-ci n'était plus actif après.
Il se trouve qu'il s'agit de la ligne de commande GRUB_CMDLINE_LiNUX.

Après installation du driver Nvidia (akmod) :
GRUB_CMDLINE_LINUX="rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init amd_pstate.shared_mem=1 rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init"
Après modification et reboot, amd_pstate fonctionne bien.
GRUB_CMDLINE_LINUX="rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init amd_pstate.shared_mem=1 rhgb quiet"
Du coup il ne doit pas y avoir de vérification si les options sont déjà là et donc il rajoute en plus... Et donc cela fait des doublons/triplons...

Au passage ton 5600x tu l'overclock? vu que sur un autre sujet tu dis que tu dépasse les 5Ghz (au lieu des max 4,6Ghz de base sur un cœur https://www.amd.com/fr/products/cpu/amd-ryzen-5-5600x ).
Pas d'OC de mon cpu (sous windows, 4,2 GHZ).
Mais depuis amd_pstate activé sous Fedora, je passe jusqu'à 5,2 GHz sans toucher à l'UEFI. :-D