Le projet PowerTOP avance à un rythme effréné (et pour cause, Arjan y travaille à plein temps). Il y a eu 5 releases depuis la rédaction du journal (de la 1.0 on est aujourd'hui à la version 5) !
Quelques compléments d'infos donc :
* Avant que je journal soit « niouzifié », j'ai écrit d'autres compléments d'informations ici : http://linuxfr.org/comments/831869.html#831869
* Keith Packard, développeur d'Xorg, témoigne : « Avec PowerTOP, j'ai réussi à améliorer l'autonomie de mon portable Panasonic R4 de 4 heures à presque 7 heures » [http://www.linuxpowertop.org/success.php] Bref, attendez vous à des progrès sensibles !
* Le panel des suggestions proposées par l'outil s'étend maintenant à l'espace utilisateur. Il est désormais capable d'appliquer certaines des propositions lui-même, à la volée.
* L'affichage utilise désormais ncurses, et c'est plus confortable.
* PowerTOP est intégré dans les versions de développement de la plupart des distributions maintenant.
* Il est désormais traduit en français, et doté d'une page de manuel.
* Les développeurs de Gaim Pidgin ont déjà sorti une nouvelle version, 2.0.1 corrigeant les problèmes levés par PowerTOP. Bravo !
* L'astuce « Option "NoDRI" » indiquée pour le problème des drivers i915 fonctionne aussi pour les drivers radeon et fglrx
* Vous verrez peut-être "i8042" assez haut dans la liste des causes de réveils. Il s'agit du pilote clavier. Le problème est connu.
* Vous verrez peut-être aussi des choses comme "[interrupt] : ide1" (ou libata ou ide0 " alors que vous ne pensez pas utiliser les disques. C'est probablement hald qui les surveille (re-testez après avoir tué hald).
* Si l'une des applications les plus gourmandes sur votre système affiche des select() ou poll() en boucle lorsque vous faites "strace -tt -p $(pidof monapplication)", ce n'est probablement pas normal, les développeurs ont probablement choisi des timeout trop courts.
* Beaucoup de gens se demandent pourquoi ils ne voient pas les C-states C3 et C4 sur leur machine. 1) essayez après avoir débranché le cable d'alim (sur batterie, quoi). 2) tout les processeurs/BIOS ne supportent pas ces C-states (attention à la confusion : /proc/acpi/processor/*/power indique "max_cstate: C8", mais c'est seulement le nombre de C-states que supporte le noyau Linux, pas le nombre physiquement implémenté dans le matériel).
* On vois beaucoup de confusion au sujet de HPET sur la m-l de PowerTOP. Je vais donc essayer de préciser. HPET est une source d'évenements temporels (une « event source for timers ticks », pas une « clocksource ») alternative au traditionnel mais ancien PIT. PIT a une grosse limitation : il ne peut dormir plus de 26ms, et génère donc en conséquence une trentaine d'interruptions par secondes (symptôme : PowerTOP affiche quelque chose du genre : « ( 27.3) [interrupt] : extra timer interrupt »). HPET est théoriquement supporté par le matériel récent (mais pas toujours), mais il faut qu'il soit activé dans le noyau, et surtout, que le BIOS ne le masque pas (ce qui est très courant : les mauvaises langues disent que les fabriquants de portables le masquent parce que, n'étant pas supporté par WinXP, cela afficherai un point d'exclamation jaune dans le gestionnaire de périphérique de Windows). Sur le site de PowerTOP, on trouve une solution à ce problème : un patch noyau qui force l'activation d'HPET, nonobstant les indications du BIOS. Bref, il ne suffit pas d'avoir HPET dans le noyau pour qu'il soit actif sur votre système : pour le vérifier, grep "Clock Event Device" /proc/timer_list .
Un petite déception : très peut d'utilisateurs témoignent des problèmes qu'ils rencontrent (pourtant Arjan est très newbie friendly. Franchement) et n'indiquent pas leurs découvertes d'applications ou modules noyau les plus gourmands (condition sine qua non pour que le problème soit corrigé). À moins que les utilisateurs de PowerTOP soient tout simplement très peu nombreux.
Visiblement, beaucoup semblent penser que « quelqu'un l'a déjà fait, un autre développeur du logiciel gourmand foo doit probablement avoir utilisé powertop » (remarque que j'ai plusieurs fois reçu lorsque j'ai indiqué des problèmes découverts par PowerTOP à des développeurs).
En réalité, peu de projets sont avertis de ces problèmes, et on découvre chaque jour des applications pourtant extrêmement utilisées dont personne n'a reporté le comportement inadéquat. La possibilité d'identifier ces comportements facilement est très récente, et le champs très vaste, c'est une véritable forêt vierge. En conséquence il reste énormément d'environnements logiciels à défricher, énormément de low hanging fruits à ramasser, c'est très facile, alors venez vous amusez ! :)
# Autres compléments d'informations
Posté par herodiade . En réponse à la dépêche PowerTOP : Un outil pour réduire la consommation d'énergie sous GNU/Linux. Évalué à 10.
Quelques compléments d'infos donc :
* Avant que je journal soit « niouzifié », j'ai écrit d'autres compléments d'informations ici : http://linuxfr.org/comments/831869.html#831869
* Keith Packard, développeur d'Xorg, témoigne : « Avec PowerTOP, j'ai réussi à améliorer l'autonomie de mon portable Panasonic R4 de 4 heures à presque 7 heures » [http://www.linuxpowertop.org/success.php] Bref, attendez vous à des progrès sensibles !
* Le panel des suggestions proposées par l'outil s'étend maintenant à l'espace utilisateur. Il est désormais capable d'appliquer certaines des propositions lui-même, à la volée.
* L'affichage utilise désormais ncurses, et c'est plus confortable.
* PowerTOP est intégré dans les versions de développement de la plupart des distributions maintenant.
* Il est désormais traduit en français, et doté d'une page de manuel.
* Les développeurs de Gaim Pidgin ont déjà sorti une nouvelle version, 2.0.1 corrigeant les problèmes levés par PowerTOP. Bravo !
* L'astuce « Option "NoDRI" » indiquée pour le problème des drivers i915 fonctionne aussi pour les drivers radeon et fglrx
* Vous verrez peut-être "i8042" assez haut dans la liste des causes de réveils. Il s'agit du pilote clavier. Le problème est connu.
* Vous verrez peut-être aussi des choses comme "[interrupt] : ide1" (ou libata ou ide0 " alors que vous ne pensez pas utiliser les disques. C'est probablement hald qui les surveille (re-testez après avoir tué hald).
* Si l'une des applications les plus gourmandes sur votre système affiche des select() ou poll() en boucle lorsque vous faites "strace -tt -p $(pidof monapplication)", ce n'est probablement pas normal, les développeurs ont probablement choisi des timeout trop courts.
* Beaucoup de gens se demandent pourquoi ils ne voient pas les C-states C3 et C4 sur leur machine. 1) essayez après avoir débranché le cable d'alim (sur batterie, quoi). 2) tout les processeurs/BIOS ne supportent pas ces C-states (attention à la confusion : /proc/acpi/processor/*/power indique "max_cstate: C8", mais c'est seulement le nombre de C-states que supporte le noyau Linux, pas le nombre physiquement implémenté dans le matériel).
* On vois beaucoup de confusion au sujet de HPET sur la m-l de PowerTOP. Je vais donc essayer de préciser. HPET est une source d'évenements temporels (une « event source for timers ticks », pas une « clocksource ») alternative au traditionnel mais ancien PIT. PIT a une grosse limitation : il ne peut dormir plus de 26ms, et génère donc en conséquence une trentaine d'interruptions par secondes (symptôme : PowerTOP affiche quelque chose du genre : « ( 27.3) [interrupt] : extra timer interrupt »). HPET est théoriquement supporté par le matériel récent (mais pas toujours), mais il faut qu'il soit activé dans le noyau, et surtout, que le BIOS ne le masque pas (ce qui est très courant : les mauvaises langues disent que les fabriquants de portables le masquent parce que, n'étant pas supporté par WinXP, cela afficherai un point d'exclamation jaune dans le gestionnaire de périphérique de Windows). Sur le site de PowerTOP, on trouve une solution à ce problème : un patch noyau qui force l'activation d'HPET, nonobstant les indications du BIOS. Bref, il ne suffit pas d'avoir HPET dans le noyau pour qu'il soit actif sur votre système : pour le vérifier, grep "Clock Event Device" /proc/timer_list .
Un petite déception : très peut d'utilisateurs témoignent des problèmes qu'ils rencontrent (pourtant Arjan est très newbie friendly. Franchement) et n'indiquent pas leurs découvertes d'applications ou modules noyau les plus gourmands (condition sine qua non pour que le problème soit corrigé). À moins que les utilisateurs de PowerTOP soient tout simplement très peu nombreux.
Visiblement, beaucoup semblent penser que « quelqu'un l'a déjà fait, un autre développeur du logiciel gourmand foo doit probablement avoir utilisé powertop » (remarque que j'ai plusieurs fois reçu lorsque j'ai indiqué des problèmes découverts par PowerTOP à des développeurs).
En réalité, peu de projets sont avertis de ces problèmes, et on découvre chaque jour des applications pourtant extrêmement utilisées dont personne n'a reporté le comportement inadéquat. La possibilité d'identifier ces comportements facilement est très récente, et le champs très vaste, c'est une véritable forêt vierge. En conséquence il reste énormément d'environnements logiciels à défricher, énormément de low hanging fruits à ramasser, c'est très facile, alors venez vous amusez ! :)