samedi 11 octobre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: PowerTOP : Un outil pour réduire la consommation d'énergie sous GNU/Linux

Posté par Florent Zara (Jabber id, page perso, ). Modéré le 15 mai 2007.
0
Serait-ce l'un des premiers bénéfices de la nouvelle orientation d'Intel en faveur de Linux pour leur solutions mobiles ?

Arjan van de Ven, développeur chez Intel, vient d'annoncer la sortie d'un outil permettant d'identifier les applications et pilotes Linux les plus gourmands en énergie de façon très simple et lisible : PowerTOP liste ces mauvais citoyens en ordre décroissant, à la façon de l'utilitaire top. Il indique aussi le nombre d'éveils des processeurs par seconde et une estimation de la consommation actuelle en watt. Très facile d'utilisation, l'outil affiche même des conseils d'amélioration en fonction de votre configuration noyau (par exemple il recommande, si ce n'est déjà fait, d'activer NO_HZ, CONFIG_USB_SUSPEND, CONFIG_HPET et CONFIG_CPU_FREQ_GOV_ONDEMAND et de désactiver CONFIG_IRQBALANCE et CONFIG_ACPI_DEBUG). Pas besoin d'être un développeur chevronné donc : tout utilisateur de GNU/Linux doté d'un PC portable devrait pouvoir utiliser cet outil (en revanche, il faut penser à signaler aux développeurs les problèmes de consommation d'énergie que cela permet de découvrir dans leurs logiciels).

Plus d'informations dans la suite de l'article

NdM: Un grand merci à herodiade, auteur du journal à l'origine de cette dépêche.

> Lire la suite (92 commentaires, moyenne: 2,2).   [dépêche : 7547 caractères]

Un noyau 2.6.21 (ou plus récent) est nécessaire au fonctionnement de PowerTOP, car celui-ci intègre le support des dynticks / tickless idle développé par Ingo Molnar et Thomas Gleixner. Cette fonctionnalité, à activer avec la nouvelle option de configuration CONFIG_NO_HZ, évite au noyau de s'éveiller hz fois par seconde s'il n'a rien à faire. PowerTOP devrait être utilisable sur les processeurs x86 non-Intel, quoique certaines informations (en particulier les informations remontées par l'ACPI concernant les C-states des CPUs) ne seront accessibles qu'avec les processeurs Intel dits « mobiles » (processeurs pour les portables).

PowerTOP détermine ces informations sur la consommation électrique en identifiant les applications et les pilotes qui « réveillent » le noyau (donc les CPUs) très fréquemment (par exemple lorsqu'on utilise une mauvaise API pour surveiller un fichier, un répertoire, un changement d'heure, la connexion d'un périphérique USB, un changement de configuration réseau, lorsqu'un pilote est sollicité en permanence par des nuées d'IRQ, ...) ou les applications qui réveillent régulièrement le noyau pendant trop longtemps. En effet, les fonctionnalités ACPI d'économie d'énergie ne sont réellement effectives que lorsque le noyau maintient les processeurs dans un des états (C-state) de repos (C3, ou mieux, C4) ; toute application qui sollicite le noyau très fréquemment (par un appel système par exemple) - même pour une tâche très simple, rapide, sans gros calculs - conduit les CPUs à basculer en mode « non économique » (C-states C0 ou C1). L'ajout d'une fonctionnalité permettant d'identifier les applications les plus consommatrices en accès disques (très gourmands en énergie) est envisagée.

Pour les développeurs, et de façon plus synthétique : si votre application surveille (en anglais « poll », « monitor », ...) en permanence le système pour être avertie de changements d'états potentiels (par exemple l'arrivée de données dans un répertoire ou sur une socket) il est préférable d'utiliser les API (comme select(2), poll(2) et inotify(7)) permettant d'attendre passivement que le noyau la prévienne lorsque c'est utile plutôt que de réveiller le noyau plusieurs fois par seconde en vérifiant depuis l'application si le changement a eu lieu. Il convient aussi de regrouper autant que possible les lectures ou écritures sur le disque dur.

Voilà quelques exemples (plutôt centrés sur le bureau Gnome) de problèmes déjà découverts - et en général corrigés - pour l'essentiel par les développeurs d'Intel :
Voilà. À nous de jouer maintenant : avec cet outil nous pouvons très facilement repérer les gros consommateurs de ressources (pilotes et logiciels) sur nos distributions, avec notre matériel/pilotes, nos logiciels et nos configurations préférées. Apparemment, les développeurs d'Intel ne se sont pas penchés sur le bureau KDE. Il serait aussi intéressant de voir l'influence de certaines options de configuration d'xorg et de comparer les divers pilotes (par ex. "ati" vs. "radeon" vs. "fglrx" ou bien "nv" vs. "nouveau" vs. "nvidia" et l'impact de leurs options de configuration respectives comme Composite, EnablePageFlip, etc.) par exemple. N'oubliez pas : pour que les résultats soient pertinents, il faut faire tourner PowerTOP avec un noyau 2.6.21 ou plus, activer CONFIG_NO_HZ, et ne pas brancher le portable sur le secteur (tourner sur la batterie).

Il nous faut remonter les problèmes dans les systèmes de suivi des bugs des logiciels et distributions concernés. Il y aura ainsi de fortes chances pour que les prochaines versions de nos distributions nous apportent quelques heures d'autonomie supplémentaires sur nos portables ou PDA (« plusieurs heures » est un objectif à portée de main, il me semble, si l'on considère aussi que ces distributions incluront un 2.6.21+ avec « dynticks », voire un 2.6.23 avec les corrections pour hal, et peut-être les patchs d'Intel)

À vos portables !

Liens supplémentaires

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

[+] Et comme d'habitude on censure sur linuxfr.org d'autre infos plus grave

Posté par kboo () le 15/05/2007 à 08:03. (lien). Évalué à -10.

Tout d'abord désolé pour l'auteur de cet article très interressant .

J'ai déja envoyé un article sur les précédentes attaque de Microsoft sur le logiciel libre et ici personne n'en parle sur Linuxfr.org.... technique de l'autruche?... alors que c'est super important. En ce moment Microsoft a récidiver comme quoi les utilisateurs de Linux devraient payer des royalities à Microsoft pour violation de 235 de ses brevets. Aujourd'hui la Linux Foundation répond ... Mais bon comme je sais que si j'envoi encore cet article il ne sera jamais publié, alors je le met ici...

Intel

Posté par patrick_g (page perso, ) le 15/05/2007 à 08:24. (lien). Évalué à 2.

J'espère quand même que ce remarquable outil d'Intel fonctionne également avec les processeurs AMD.

Gagner beaucoup d'autonomie est possible

Posté par reno () le 15/05/2007 à 08:25. (lien). Évalué à 4.

Je me souviens avoir vu dans des comparatifs que Windows fournit une autonomie bien supérieure a celle de Linux sur des portable, et ce sont des grosses différence genre 2h30 avec Linux et 4h avec Windows.

Donc c'est possible mais cela ne sera pas ni simple ni rapide: dans la discussion sur lkml, il était fait allusion au fait que hal fait un poll toutes les 2 secondes et un patch pour utiliser un mécanisme des disques SATA pour éviter ça, patch prévu pour 2.6.23..
Et toutes les applications userspaces a tester!

Et les serveurs

Posté par Nicolas Delsaux (page perso, ) le 15/05/2007 à 08:28. (lien). Évalué à 6.

C'est une super idée, et c'est génial pour les utilisateurs de portables. Mais comment ça va se répercuter au vrai marché de Linux, c'est-à-dire les serveurs.
En effet, sur un portable, le but, c'est de gagner de l'autonomie, et donc de diminuer la consomation.
Mais on retrouve, à mon sens, la même problématique de consomation chez les serveurs (quoique ce soit cette fois-ci dicté par des impératifs de facture EDF).
Donc, ma question est simple : si j'ai un serveur chez moi (ce qui est le cas), sous Linux (ce qui est aussi le cas), et que je souhaite optimiser (ou plutôt diminuer) sa consomation électrique, est-ce que je vais moi aussi bénéficier des améliorations apportées grâce à PowerTOP ?
En apparté, j'ai quand même l'impression qu'il s'agit plus d'un logiciel pour développeurs que pour utilisateurs classiques, non ?

--
"Putain, mais quelle fichue imagination je peux avoir ! ..."
John Brunner - Tous à Zanzibar

mise en sommeil complete d'un serveur

Posté par kesako () le 15/05/2007 à 09:00. (lien). Évalué à 4.

j'ai plusieurs machines (pas des portables) qui tournent 24h/24 mais n'ont absolument rien a faire la nuit.

Je les ai donc configurées pour que vers 23h tous les services , les interfaces, X et le reste soient arretés . Il ne reste pratiquement que l'OS tout nu , cron et le disque qui marchent. Au matin , tout redemare.

Je voudrais que le disque s'arrête lui aussi.

dans le temps, j'utilisais noflushd pour que le disque se mette lui même en sommeil . c'etait ok.
Mais depuis le noyau 2.6 et les systemes de fichiers journalisés ce n'est plus possible car, parrait-il, ils bypassent le mécanisme d'écriture du kernel.

quelqu'un connait-il le moyen de mettre en sommeil un disque systeme piloté par linux 2.6 et ayant des partitions ext3 et/ou reiserfs quand l'os ne fait absolument rien ?

[+] Un grand merci ...

Posté par pipo_molo () le 15/05/2007 à 09:01. (lien). Évalué à -7.

C'est quand même louche, une news qui papparaît deux jours après le journal, et qui repompe son contenu à 100%, avec juste le nom de l'auteur qui change, sans avoir de problème à passer la modération.

Je me serais attendu à mieux, sur un site d'intaigristes du copyleft.

"Pas besoin d'être un développeur chevronné donc"

Posté par dco () le 15/05/2007 à 11:44. (lien). Évalué à 0.

mouais...

Petit test : download du tar.gz, le make passe sans problème et donc je lance gaiement le powertop et..... rien :


No detailed statistics available; please enable the CONFIG_TIMER_STATS kernel option
This option is located in the Kernel Debugging section of menuconfig
(which is CONFIG_DEBUG_KERNEL=y in the config file)


Il faut donc avoir qd mm un noyau compilé avec cette option (pas le cas dans le noyau ubuntu feisty que j'utilise) même uniquement pour faire un diagnostique (et sans forcement vouloir customiser les params).

du coup, j'hésite à recompiler mon noyau que pour ça...

[+] Firefox

Posté par Kévin LAPETOULE (page perso, ) le 15/05/2007 à 15:15. (lien). Évalué à -3.

A gay man that only tops tops, even if they are total tops. This would imply a DOUBLEPLUS alpha-male syndrome.

«aqua_vitae» I'm a powertop.
«aqua_vitae» my bf was a top when i met him; hes never fucked me

En complément

Posté par Remi (Jabber id, ) le 15/05/2007 à 15:45. (lien). Évalué à 1.

Bonjour,

tout d'abord merci pour la dépèche (et le journal) sur ce sujet.

Pour ceux qui sont intéressés pour sauvegarder mieux leurs batteries / consommer moins tout ça, vous pouvez parcourir le "Linux-Ecology howto" :

http://computerecology.org/

"Linux can be used as a means to protect our environment, by using its features to save power or paper, since it doesn't require big hardware it may be used with old computers to make their life cycle longer, games may be used in environmental education and software is available to simulate ecological processes. I described this means in the Linux-Ecology-HOWTO. "

++

Autres compléments d'informations

Posté par herodiade () le 29/05/2007 à 14:02. (lien). Évalué à 10.

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 ! :)

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 10.6164s (dont 0.0302 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !