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(1). Il indique aussi le nombre d'éveils des processeurs par seconde et une estimation de la consommation actuelle en watt. Très user friendly, 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 mais 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 ;).

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équement (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 application 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 tache 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 d'accès disques (très gourmands en énergie) est envisagée.

Pour les développeurs, et de 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.

Voila quelques exemples (plutôt centrés sur le bureau Gnome) de problèmes déjà découverts - et en général, patchés - pour l'essentiel par les développeurs d'Intel :

• Certaines options du noyau ont une influence considérable (voir les recommandation indiquées plus haut).


• Certains logiciels se révèlent très gourmands, et réveillent le noyau des centaines, voir des milliers de fois par secondes alors que des solutions alternatives existent. Firefox, Evolution, gnome-power-manager, gaim (maintenant appelé Pidgin), ntpd (celui de ntp.org, pas openntpd, qui est mieux ;), dhcdbd, le mixer_applet2 de gnome, les pilotes intel i915 et ipw2100, les pilote appletouch (pour les macs) et ibm_acpi se sont révélés être de très grands consommateurs de ressources. Intel a écrit un patch dans la plupart des cas.


• L'utilisation des graphismes 3D est souvent très gourmande (il faut donc éviter Beryl/Compiz lorsque son portable tourne sur batterie et qu'on veut économiser de l'énergie).


• Une simple animation persistante dans le navigateur web force xorg à se réveiller régulièrement. Plus intéressant : le curseur clignotant (blinking cursor) du terminal gnome réveille xorg très souvent, même lorsque le terminal n'a pas le focus ou lorsqu'il est en arrière plan. Vous pouvez désactiver ce clignotement à partir des options de configuration de gnome-terminal.


• Sur un macbook, on gagne une heure d'autonomie lorsqu'on décharge le module uhci_hcd (note : ce module est nécessaire pour avoir le support du clavier, mais ça donne une indication utile pour les développeurs).

Voila. À 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és. 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 bugstrackers 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 », voir un 2.6.23 avec les corrections pour hal, et peut-être les patchs d'Intel) :)

• Le site de PowerTOP : http://www.linuxpowertop.org/


• Explications sur son fonctionnement : http://www.linuxpowertop.org/powertop.php


• Problèmes déja découverts (firefox, gaim, ...), conseils divers et patchs proposés : http://www.linuxpowertop.org/known.php


• La liste de diffusion de PowerTOP : http://www.bughost.org/pipermail/power/2007-May/thread.html . Voir aussi le canal IRC #powertop sur the irc.oftc.net.


• L'annonce sur LKML (la liste de diffusion des développeurs du noyau linux) : http://lkml.org/lkml/2007/5/11/365 (voir aussi les messages concernant uhci_hcd sur les macbooks http://lkml.org/lkml/2007/5/12/223 ou des problèmes avec hal http://lkml.org/lkml/2007/5/12/149 ).


• Quelques liens montrant la suractivité actuelle d'Intel pour développer des plateformes mobiles basées sur Linux : http://softwarecommunity.intel.com/articles/eng/1093.htm , http://www.intel.com/pressroom/archive/releases/20070417supp(...) , https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007(...) , http://www.mobilelinuxinfo.com/278/intel-to-push-linux-based(...) .


• Plus d'information sur la nouvelle fonctionalité « dynticks » du noyau 2.6.21 : http://lwn.net/Articles/223185/ et http://kerneltrap.org/node/7749


• Les C-states et l'ACPI sur les processeurs mobiles Intel : http://www.intel.com/technology/itj/2006/volume10issue02/art(...)

À vos portables ! ;)

> Lire le journal (30 commentaires, moyenne: 3,3).