Gestion de l'énergie : se dépêcher de ne rien faire

Posté par . Modéré par Christophe Guilloux.
3
16
mai
2008
Noyau
Je vous propose la traduction de deux courts articles de Matthew Garrett publié sur Livejournal sur l'historique et l'intérêt des états de sommeil des processeurs x86 modernes et de la réduction de fréquence.

« Certaines personnes écrivent des logiciels qui vous permettent de choisir différents réglages selon que vous être branché sur le secteur ou sur batterie. Typiquement, l'un de ces choix vous permet de réduire la fréquence du processeur lorsque vous êtes sur batterie. Ceci est mauvais. Ceci est faux. Les personnes qui implémentent ces programmes sont dangereuses... » Les processeurs modernes sont fantastiques. Ils ont toutes sortes de fonctionnalités d'économie d'énergie ; c'est l'un de ces cas où tout le monde peut économiser de l'argent, augmenter les performances et prétendre préserver l'environnement en même temps. Tout le monde y gagne.

Hmmm, tout le monde y gagne à condition que votre logiciel ne soit pas mal fichu.

J'ai déjà écrit à propos des bénéfices des noyaux sans horloge (tickless), de la réduction du nombre de réveil du processeur et du fait de passer plus de temps dans les états C[0a] par le passé ; si vous ne connaissez pas ces choses, je vous invite à aller les lire en premier[0b]. Cette fois ci, je vais me concentrer sur un autre niveau matériel, et sur un autre niveau de choses mal fichues.

Depuis longtemps, les ordinateurs portables supportent le changement de fréquence du processeur selon que le portable est branché ou sur batterie. La consommation du processeur est proportionnelle à la fréquence, donc abaisser la fréquence entraîne une augmentation de l'autonomie. Bien sur, cela signifie aussi qu'il faut plus de temps pour faire une tache donnée. La raison pour laquelle ceci était quand même un gain, est qu'à cette époque les processeurs consommaient exactement autant d'énergie, qu'ils fassent quelque chose ou non. La société Transmeta a introduit une technologie appelée Longrun dans leurs processeurs Crusoe ; permettant de faire baisser simultanément la fréquence et la tension du processeur. Comme la consommation électrique est proportionnelle au carré de la tension, même une petite réduction de la tension provoque une économie d'énergie valable. Comme c'était la seule innovation intéressante apportée par Transmeta dans le monde du x86[1], de manière toute logique, cette amélioration a été copiée par tout le monde : Intel a développé sa technologie Enhanced Speedstep, AMD a proposé PowerNow et VIA a Longhaul.

Naturellement, réduire la fréquence du processeur augmente l'autonomie. Tout le monde est content ?

Non[2].

Le problème est que de nos jours, les processeurs ne consomment pas autant d'énergie lorsqu'ils ne font rien que lorsqu'ils travaillent. Les niveaux C préalablement mentionnés signifient qu'un processeur en sommeil ne consomme qu'un faible pourcentage de l'énergie consommée par un processeur actif - un processeur Intel ultra-basse tension a une consommation de l'ordre du watt. Exécuter du code, même à la plus basse tension et fréquence, consomme bien plus d'énergie. Par conséquent, nous voulons conserver le processeur en sommeil aussi longtemps que possible. La façon la plus facile de faire cela est de ne jamais rien exécuter, mais cela n'est pas une option valable. La solution alternative est de fonctionner lorsque cela est nécessaire, mais de s'assurer que cela soit fait le plus rapidement possible afin de retourner en état de sommeil. De manière contre-intuitive, cela signifie basculer à la plus haute tension et à la plus haute fréquence, exécuter le code, puis retourner en état de sommeil. En allant plus vite, nous économisons de l'énergie[3].

En résumé, la seule façon logique d'utiliser un processeur est de le faire fonctionner aussi rapidement que possible afin de lui permettre de passer le plus de temps possible en état de sommeil, situation dans laquelle la fréquence et la tension sont au minimum. La seule façon *logique*.

Certaines personnes écrivent des logiciels qui vous permettent de choisir différents réglages selon que vous être branché sur le secteur ou sur batterie. Typiquement, l'un de ces choix vous permet de réduire la fréquence du processeur lorsque vous êtes sur batterie. Ceci est mauvais. Ceci est faux. Les personnes qui implémentent ces programmes sont dangereuses. Ne les écoutez pas. N'approuvez pas leurs produits et leurs communiqués. Ne laissez pas votre fils aîné avoir des relations conjugales avec eux. Cela réduira l'autonomie de votre batterie, augmentera la température de votre maison, tuera les bébés phoques, fera monter le niveau de l'océan et emportera votre voiture. Si vous l'utilisez déjà, assurez vous qu'il utilise systématiquement la politique "ondemand" de cpufreq et qu'il ne limite pas les fréquences utilisées. J'incendierai personnellement tout contrevenant[4].

La seule raison légitime pour réduire la fréquence du processeur est de limiter la surchauffe (ce qui doit être fait dans le noyau - avoir un programme utilisateur chargé d'assurer le bon fonctionnement de la machine est une ânerie) ou rendre la machine plus silencieuse. Et si vous voulez une machine plus silencieuse, il devrait y avoir une case à cocher : "Réduire les performances afin de réduire le bruit" qui prenne en compte toutes les sources de chaleur de votre machine et non juste le processeur. Encourager la gestion du niveau sonore en demandant aux utilisateurs de réduire la puissance de leurs processeurs est une façon de dire "Regardez, nous avons mal conçu le système !". Laisser l'utilisateur choisir une politique de gestion du processeur ou une fréquence particulière n'est pas une bonne chose. Ne le faites-pas, à moins de vouloir voir des chatons morts, livrés par UPS.

[0a] NdT : Les états C (C1, C2...) sont des états ACPI normalisés dans lesquels il est possible de basculer le processeur afin lui faire économiser de l'énergie ; cela se traduit par un temps de réponse plus important, la purge des caches, l'arrêt de certaines horloges internes... Le processeur ne peut exécuter des instructions qu'au niveau C0, le retour à cet état est d'autant plus long que le processeur est à un niveau de sommeil profond.

[0b] NdT : Ces articles ne sont pas traduits ici, mais sur l'absence d'horloge, je vous invite à lire "Timers haute résolution et horloge dynamique" : http://linuxfr.org/2006/06/30/21038.html

[1] Et, probablement, toutes les licences qu'Intel et les autres ont fini par acquérir, ce qui transforme Transmeta en entreprise de gestion de la propriété intellectuelle et non en fabricant de processeur, mais ce n'est pas notre sujet.

[2] Même en ignorant toutes les personnes qui sont mécontentes pour des raisons totalement étrangères au sujet comme ceux qui se sont cogné le petit orteil ce matin ou ceux dont la famille a été soudainement assassinée.

[3] Il y a un cas particulier ici : c'est celui d'un système qui est constamment occupé. Imaginons que nous divisons par deux la vitesse du processeur. Avec la réduction de tension, cela entraîne une consommation réduite à 20% de la consommation initiale. Bien évidement, toutes les taches prennent maintenant deux fois plus de temps ; et votre écran, votre mémoire, votre disque dur, chipset et tout le reste continuent à consommer de l'énergie ; au final vous consommez deux fois plus d'énergie qu'il en aurait fallu à pleine vitesse. En faisant le calcul, on détermine que l'on économise de l'énergie si la consommation du processeur à pleine vitesse est de plus de 1,7 fois le reste de la plate-forme. Dans le monde réel, les choses se compliquent car les autres composants consomment également plus d'énergie s'ils fonctionnent plus longtemps : le disque dur sera actif pendant plus longtemps, le bus mémoire sera occupé pendant plus longtemps... Vous n'êtes pas, en principe, dans ce cas de 1,7 fois plus.

[4] Bien que la combustion de votre corps provoque une émission de carbone, la réduction énergétique consécutive entraîne un bilan positif sur le long terme.


Éclaircissements postés le lendemain:

Mon précédent article a été un peu trompeur sur un point : le débat sur la consommation d'un processeur à fréquence réduite. Le problème est que de nos jours, diviser par deux la fréquence d'un processeur ne réduit pas par deux la consommation électrique (voir les graphiques des diapositives de Arjan à l'OSCON l'année dernière par exemple). Je suppose que cela est dû aux mémoires cache qui représentent une part importante de la consommation. Réduire la fréquence ne réduit pas l'énergie nécessaire pour maintenir le contenu de ce cache ; par conséquent, la réduction énergétique est plus faible que prévue. Les niveaux C de sommeil les plus profonds désactivent le cache et économisent plus d'énergie.

Par conséquent, si diviser par deux la fréquence signifie que tout prend deux fois plus de temps mais ne réduit pas par deux la consommation électrique, quel est l'intérêt d'avoir des fréquences réduites ? Il faut un certain délai et une certaine quantité d'énergie pour changer d'état C ; et si le choix est entre basculer continuellement de la pleine vitesse à l'état C4 ou simplement rester à vitesse réduite (en passant éventuellement à l'état C1 ou C2), alors exécuter le programme à la plus faible fréquence peut être bénéfique. La politique "ondemand" du noyau Linux prend en compte la charge du processeur à travers le temps ; si une certaine valeur de seuil n'est pas atteinte, il considérera qu'il vaut mieux rester à la plus basse fréquence.
  • # Why ?

    Posté par . Évalué à 7.

    L'écriture de ces 2 articles n'est pas anodine, Matthew Garrett a été embauche par RedHat fin mars pour travailler sur l'aspect gestion d'énergie dans Linux.
    D'ailleurs, je recommande la lecture des billets précédents qui sont tout aussi intéressants autour ce sujet (ACPI, interaction pilotes graphiques/gestion d'énergie)

    http://www.flickr.com/photos/kernelslacker/1397519526/
  • # Ondemand

    Posté par . Évalué à 2.

    Tout le monde sait qu'il faut laisser son proc en ondemand via cpufreq, non?

    Mais il y a des exceptions: mattage de film ou de flash
    • [^] # Re: Ondemand

      Posté par (page perso) . Évalué à 2.

      D'ailleurs je me demande comment ils font sur les autres OS (Mac OS par exemple) pour avoir une politique ondemand vis à vis de la fréquence sans que cela soit gênant dans des cas particuliers (vidéo, flash ...)

      Quelqu'un sait comment ils font ?

      Je dis tout ça parce que j'aimerais bien me débarasser du moniteur de fréquence CPU sur mon panel gnome ... qui me prend trop de place... et que je garde unisuement pour passer en mode performance dans certains cas particuliers.
      • [^] # Re: Ondemand

        Posté par . Évalué à 3.

        Sous MacOSX c'est gênant en cas de vidéo, flash, ...

        En tout cas, il faut quelques instants à mon G4@1.25Ghz pour se "réveiller" et alimenter ce puits sans fond de puissance CPU qu'est Flash.

        BeOS le faisait il y a 15 ans !

      • [^] # Re: Ondemand

        Posté par (page perso) . Évalué à 3.

        Perso j'utilise cpufreq_ondemand sur mon portable et je n'ai jamais vu de probleme pour la lecture de vidéo ou du flash...

        Apres, peut etre qu'avec cpufreq_userspace et un programme genre powernowd/cpufreqd, ca pose des problemes.
    • [^] # Re: Ondemand

      Posté par . Évalué à 5.

      Bonjour,

      Je le laisse systématiquement et dans tous les cas sur Ondemand. Je n'ai jamais rencontré de problème, cela marche parfaitement. J'ai un pentium M.
      Pour vraiment gagner en autonomie, il faut jouer sur une multitude de paramètres.
      Pour ceux qui ne connaissent pas, je recommande l'outil powertop et le site http://www.lesswatts.org. En suivant toutes les recommandations j'ai pratiquement doublé l'autonomie de mon T40, sans rencontrer de désagrément.
      • [^] # Re: Ondemand

        Posté par . Évalué à 1.

        Mon CPU, un pentium M, le fait tout seul: 2.13GHz en cas de forte charge et 800MHz en cas de charge faible. Je n'ai pas vu de pallier intermédiaire.
        Lors du visionnage d'une vidéo mpeg4 sous kmplayer, il reste constamment à 800MHz. C'est plutôt bon signe.
        Je suppose que c'est indépendant de l'OS ?
  • # pas convaincu.

    Posté par . Évalué à 2.

    Il faut faire les calculs.

    En etant autant de mauvaise foi que Matthew..

    si P_C2 = 1W
    si P_C0_2GHZ = 20W
    si P_C0_1GHZ = 10W

    pour n'importe quelle tache qui dure 1sec en mode 2GHZ

    mode je me depeche de ne rien faire:
    Q(2s) = P_C0_2GHZ*1s + P_C2*1s + Q_C0_TO_C2
    = 20Ws + 1Ws + ..
    mode basse frequence:
    Q(2s) = P_C0_1GHZ*2*T
    = 20Ws
    • [^] # Re: pas convaincu.

      Posté par . Évalué à 6.

      Traduction approximative d'un message plus récent de l'auteur sur son blog :

      « Le problème est que de nos jours, diviser la fréquence du processeur par deux _ne divise pas_ la consommation par deux. Je suppose que c'est dû à la taille du cache (...). Baisser la fréquence ne réduit pas la puissance nécessaire au maintien du cache, et les économies sont moindres que ce que l'on peut attendre. Des C states plus avancés désactivent le cache et économisent davantage d'énergie.

      Donc, si diviser la vitesse par deux signifie que tout prend deux fois plus de temps mais que la consommation d'énergie n'est même pas divisée par deux, quel est l'intérêt d'avoir des P states ? »

      Dans ton exemple ce serait du P_C0_2GHZ = 20W et P_C0_1GHZ = 12W
      • [^] # Re: pas convaincu.

        Posté par . Évalué à 10.

        Effectivement,
        Avec les anciennes technologie CMOS la conso est proportionnelle a la frequence : on dépense de l'energie pour charger et decharger les capacités des transistors qui changent d'etat. donc plus ca commute plus ca consomme. Les fondeurs donnent d'ailleur la conso de leur porte en microWatt/MHz.
        Avec les techno recentes disons a partir de 90 nm, en plus de cette conso liée
        aux commutations, il y a une consommation statique liée aux fuites des transistors (ils sont tellement petis que meme en position "off", ils laisent passer un peu de courant : pas beaucoup, mais comme ils sont nombreux, ca fini par faire des watts. Ca c'est indépendant du travail du proc, c'est juste lié
        a la technologie et au nombre de porte dans le circuit. Plus on descend en
        dimmension plus cette conso statique devient importante. A 45 nm, soit les techno de maintenant, c'est la cata. D'apres certain il peu y avoir presque autant de conso statique que dynamique.

        Voila pour ce que je sais sur la conso des circuits. Apres il y a des methodes
        pour optimiser la conso lors de la conception (compromis vitesse/conso) donc
        dans les parties moins critiques on met des transistors différents qui consomment moins mais qui pedalent moins vite. Ensuite au niveau OS c'est pas mon domaine donc ---------->
        • [^] # Re: pas convaincu.

          Posté par (page perso) . Évalué à 2.

          Merci de cette très bonne explication.
          Il serait donc logique que la loi de Moore arrive en butée à moins que l'ordinateur quantique ne prenne la relève. De toutes façons, on ne descendra pas au dessous d'un électron prisonnier de d'une maille de cristal.
        • [^] # Re: pas convaincu.

          Posté par . Évalué à 10.

          "A 45 nm, soit les techno de maintenant, c'est la cata."
          Faux !
          Voir l'article de Science&Vie qui explique comment Intel est parvenu au 45nm.
          Effectivement avec les matériaux des transistors 90nm, passer en 45nm était une cata, ça consommait autant on que off (tests labos).
          C'est pour ça qu'ils ont attendu de découvrir les propriétés de l'oxyde d'Haffnium pour passer en 45nm. Et là plus de fuites, l'oxyde d'haffnium est le "Pampers" des transistors modernes.
          Enuites, les autres fondeurs (AMD, VIA) on mis du temps à intégrer le 45nm parceque la dépose de l'oxyde d'affnium est très délicate, et se fait par dépose d'un gaz sur un solide. Difficile à maîtriser.

          Donc oui, quand on réduit la taille des transistor, on augmente les fuites, mais les fondeurs sont pas cons non plus, ils cherchent uns solution avant que ça ne serve plus à rien de miniaturiser !
          De toutes manières, des limites physiques sont en train d'être atteintes, on ne trouvera pas éternellement d'élément capable de réduire les fuites sans nuire à la conductibilité. Il faudra trouver un successeur au transistor ou se tourner vers la physique quantique.
          • [^] # Re: pas convaincu.

            Posté par . Évalué à 3.

            Si ma mémoire est bonne VIA n'est pas un fondeur, ils utilisent les services de fondeurs tels que TSMC..
          • [^] # Re: pas convaincu.

            Posté par . Évalué à 6.

            "la dépose de l'oxyde d'affnium est très délicate, et se fait par dépose d'un gaz sur un solide. Difficile à maîtriser."

            Peut être que s'est délicat pour pas mal de paramêtres mais certainement pas par le fait que l'on dépose une couche sur un solide via un gaz. Tous les fabricants font cela depuis des décennies, on appèle cela CVD (Chemical Vapor Deposit) et une bonne partie des matériaux utilisés dans les processeurs sont déposé de cette manière.
          • [^] # Re: pas convaincu.

            Posté par . Évalué à 7.

            Cité un article SVM pour parler de science, c'est gonflé quand même...

            Surtout que l'on parle toujours d'amélioration, cela ne règle jamais le problème.

            "La première sécurité est la liberté"

    • [^] # Re: pas convaincu.

      Posté par . Évalué à 7.

      Son point est uniquement valable avec sa mise au point.

      D'un point de vue théorique avec un petit modèle, son argumentation est idiote.

      La consomation est P=k*fV². Si tu ne baisses que la fréquence, tu augmentes le temps de calculs, l'énergie nécessaire pour le calcul est inchangé.

      Par contre, si tu baisses la tension, tu baisses aussi la quantité d'énergie pour ton calcul. Tu y gagnes dans tous les cas.

      Si on prends un modèle plus complexe avec des grosses parties qui reste allumés (cache), le gain diminue voir devient négatif mais cela dépend des cas

      E=P*t=(k*F*V²+Pautre)*t

      t peut être mesuré en coup d'horloge, et n le nombre de cycle pour faire un calcul donné et p la période de l'horloge (1/F).
      t= n.p
      E = (k.V²/p + Pautre).n.p
      E = nkV² + Pautre.n.p

      Si V diminue la conso diminue, mais le 2ième terme devient plus important.

      "La première sécurité est la liberté"

      • [^] # Re: pas convaincu.

        Posté par . Évalué à 4.

        D'un point de vue théorique avec un petit modèle, son argumentation est idiote.

        Mais même d'un point de vue pratique. Car dans les faits, on remarque très bien les gains en autonomie.
        Je remarque que lors d'un visionnage de film, la fréquence fluctue avec des effets sur la fluidité du film or, si je décide de moi-même de faire tourner le processeur à telle fréquence moyenne - basé sur l'expérience - non seulement je n'ai pas de fluctuation mais j'aurais consommé moins que le mode "ondemand" et certainement moins qu'à pleins régime.

        Alors, qu'il critique le fait que cette gestion soit délégué à l'utilisateur, ça pourrait se comprendre car le concept est effectivement problématique, mais ici sa démonstration est mal menée.

        Néanmoins, ce n'est pas une raison pour se bloquer sur la forme, mais alors, que faire?
        Je n'ai pas encore lu son article.
        • [^] # Re: pas convaincu.

          Posté par . Évalué à 4.

          Le visionnage d'un film sort un peu du cadre de l'article. C'est une activité qui sollicite continuellement le processeur sur une longue durée. Dans ce cas, effectivement, rester à la fréquence maximale doit être néfaste. Par contre, pour une activité comme la prise de note où l'on ne saisit que par intermittence, je pense qu'il doit y avoir un gain.

          Avoir des résultats de test in situ serait intéressant. Dommage que visionner les chiffres présentés à l'OSCON l'an dernier nécessite flash. :(
          • [^] # Re: pas convaincu.

            Posté par . Évalué à 4.

            Je ne suis pas informaticien, mais à mon avis, le raisonement n'est juste que pour les taches qui prennent 100% de temps CPU pendant un laps de temps qui varie selon la fréquence.
            Ce n'est pas le cas pour une video ou de l'audio qui nécéssite assez de puissance pour respecter ses timers. Si le CPU peut l'atteindre sans être à sa fréquence maximale, ça me paraît mieux.

            En fait, il est assez rare que ma machine ait besoin de monter à sa fréquence maximale: lors d'une ouverture/extraction d'archive, par exemple, mais comme ça ne représente même pas 10% de son temps d'activitée, j'imagine que je gagne à diminuer la fréquence (pourtant, c'est un P3 1Ghz).
            • [^] # Re: pas convaincu.

              Posté par . Évalué à 1.

              Je précise que mon système est réglé sur 'ondemand' par défaut. Ca fonctionne tellement bien que je me demande dans quel cas de figure cet article devient pertinent ???
              • [^] # Re: pas convaincu.

                Posté par (page perso) . Évalué à 4.

                Les P3 1GHz n'avaient pas de variation de fréquence... à moins que ce soit sur un portable (version mobile = P3M).

                ⚓ À g'Auch TOUTE! http://agauch.online.fr

                • [^] # Re: pas convaincu.

                  Posté par . Évalué à 1.

                  Oui, c'est un bon vieux ThinkPad T23. Il tourne à 731 Mhz en conso réduite, et à 1,13 Ghz en perfs max et avec 512 Mo de RAM, il fait touner au poil une distrib actuelle (j'ai une machine plus puissante pour comparer).

                  L'article laisserait-il entendre que certains logiciels permettent de diminuer la fréquence de CPUs qui n'ont pas ce type de techno, ou est-ce juste pour critiquer un mode sur baterie ou on le ferait tourner exclusivement à fréquence réduite ?
                  • [^] # Re: pas convaincu.

                    Posté par . Évalué à 2.

                    Effectivement, sous Windows par exemple, il n'est pas rare que des outils constructeurs brident la fréquence en mode batterie. Pour ce qui est des tâches comme la lecture vidéo mentionnées ci-dessus, ondemand est effectivement assez peu adapté et il vaut mieux ne pas "trop" changer la fréquence pour plutôt rester à une fréquence juste suffisante. Pour ça, pas la peine de demander à l'utilisateur cependant : il y a conservative.
                    • [^] # Re: pas convaincu.

                      Posté par . Évalué à 2.

                      D'après ce que j'ai compris sur la page http://www.mjmwired.net/kernel/Documentation/cpu-freq/govern(...) le mode conservative augmente d'un cran la fréquence du CPU quand il dépasse le seuil demandé alors que ondemand passe directement à la fréquence maximale.

                      C'est intéressant avec un CPU plus récent qui supporte un réglage assez fin de la fréquence, mais dans mon cas, j'ai l'impression que les deux modes donnent le mêmes résultats puisque je n'ai que deux fréquences possibles. À moins qu'il n'y ait des subtilités qui m'aient échappées dans la politique et les réglages de changement de fréquence...
                      • [^] # Re: pas convaincu.

                        Posté par (page perso) . Évalué à 3.

                        Tu as raison. Ondemand par défaut accélère le CPU si on dépasse 20% d'occupation, et commence à baisser en dessous de 80%. Pour un film, sachant que la puissance demandée varie de 100% suivant les plans, ça permet de rester avec suffisament de marge pour ne jamais saccader.

                        Ayant beaucoup utilisé les démons cpufreq et powernowd, je peux vous garantir qu'ils sont aujourd'hui parfaitement inutiles, et même néfastes : ils bouffent de la RAM et du CPU pour rien.

                        ⚓ À g'Auch TOUTE! http://agauch.online.fr

                        • [^] # Re: pas convaincu.

                          Posté par . Évalué à 2.

                          T'es configuré sur quoi alors?
                          Ondemand dans le noyau et basta?
                          • [^] # Re: pas convaincu.

                            Posté par (page perso) . Évalué à 2.

                            module ondemand chargé et puis :

                            #pour activer le mode à la demande
                            echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

                            # pour que les tâches d'arrière plan (encodage ogg, etc) n'accélèrent pas le bouzin
                            echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load

                            ⚓ À g'Auch TOUTE! http://agauch.online.fr

            • [^] # Re: pas convaincu.

              Posté par . Évalué à 4.

              > le raisonement n'est juste que pour les taches qui prennent 100% de temps CPU pendant un laps de temps

              Lorsqu'une tache a du boulot et que le noyau lui passe la main, le boulot est fait à 100 % du CPU. Jamais 50 ou 25 %. Toujours 100 %. Et la tache ne passe jamais à 25 % ou 0 %, la tache passe la main au noyau lorsqu'elle a finie (ou est en attende d'une ressource, etc).
              C'est simple, un tache qui a le cpu (ou un coeur) l'a totalement à 100 %. Il ne l'a pas à 30 %, il ne peut pas décider d'utiliser que 25 % du cpu, etc. C'est 100 % et que 100 %.

              En moyenne une tache peut bouffer 25 % du cpu. Mais ça veut dire que durant 25 % du temps la tache à 100 % du cpu, et le reste du temps la tache n'a tout simplement pas le cpu.

              > En fait, il est assez rare que ma machine ait besoin de monter à sa fréquence maximale

              Ceci l'OS ne peut pas le décider. L'OS ne va pas décider que compiler un noyau en 3 heures est satisfaisant et utiliser "25 % du cpu". L'OS a une tache à faire, il la fait le plus vite possible. Toujours.
              • [^] # Re: pas convaincu.

                Posté par . Évalué à 1.

                En moyenne une tache peut bouffer 25 % du cpu. Mais ça veut dire que durant 25 % du temps la tache à 100 % du cpu, et le reste du temps la tache n'a tout simplement pas le cpu.

                Et l'idle time n'en est que plus long... Ok, je comprends mieux l'intérêt de l'article vu comme ça.
              • [^] # Re: pas convaincu.

                Posté par (page perso) . Évalué à 2.

                Cf ci-dessus, où j'indique comment dire à ondemand d'ignorer la charge 'nice' . Il suffit alors de faire 'nice make' et l'OS saura que t'es pas pressé ;-)

                ⚓ À g'Auch TOUTE! http://agauch.online.fr

      • [^] # Re: pas convaincu.

        Posté par . Évalué à 3.

        >D'un point de vue théorique avec un petit modèle, son argumentation est idiote.

        Ahem, les modèles étant souvent simpliste, ça me parait très exagéré de qualifier une argumentation "d'idiote" sur cette base.

        >La consomation est P=k*fV². Si tu ne baisses que la fréquence, tu augmentes le temps de calculs, l'énergie nécessaire pour le calcul est inchangé.

        La preuve dans le cas présent: les CPUs attendent souvent la mémoire, les IOs, et se tourner les pouces plus lentement (a frequence plus basse), ça consomme moins d'énergie que le faire plus rapidement..
  • # un peu trompeur

    Posté par . Évalué à 5.

    La grande majorité de son article n'est pas sujette à polémique mais tout n'est pas aussi tranché qu'il veut bien le faire croire.

    D'abord cela dépend bien évidemment du processeur (et oui, il existe encore des gens vaguement sensés qui ne changent pas de laptop une fois tous les deux mois) et donc il faut conserver la possibilité dans le soft d'avoir d'un comportement différent sur secteur et sur batterie.

    Ensuite il ne prend pas en compte la consommation d'un ventilateur. Si on la prend en compte, maintenir la température suffisamment basse pour éviter qu'il ne se déclenche peut être avantageux dans le bilan calculs effectués / énergie consommées.
    • [^] # Re: un peu trompeur

      Posté par . Évalué à 6.

      Il ne faut pas oublier non plus (et il le précise) que le processeur représente bien souvent un élément moins décisif qu'avant en terme de consommation.
      À quoi bon avoir un processeur peu gourmand super bien géré si à côté on a une carte graphique blobée qui chauffe à fond tout le temps, un disque dur à 7200 tpm et un écran avec la luminosité à fond ? (sans parler de chipsets inutilisés (genre le LAN quand on est en Wifi et inversement) qui ne sont pas totalement arrêtés voire consomment toujours autant que quand ils sont utilisés)
  • # Un bon test

    Posté par . Évalué à 2.

    Un bon test si vous avez un ordinateur portable.
    Dans un premier temps, configurez le systeme pour favoriser l'economie d'energie. Clic clic clic, hop, c'est fait ? Alors debranchez l'adaptateur secteur et lancez le chronometre. Travaillez comme a votre habitude jusqu'a extinction de l'ordinateur. Combien de temps a-t-il tenu ?

    Rechargez la batterie et configurez le systeme pour respecter les concepts presentes dans l'article. A nouveau, debranchez l'adaptateur secteur et lancez le chronometre. Travaillez comme a votre habitude jusqu'a extinction de l'ordinateur. Et la, combien de temps a-t-il tenu ?

    En ce qui me concerne, j'ai remarque que mon ordi tient mieux quand les economies d'energies de l'OS sont activees. Cela me rend sceptique vis-a-vis de l'article.

    Le bonjour chez vous,
    Yves
    • [^] # Re: Un bon test

      Posté par . Évalué à 2.

      > En ce qui me concerne, j'ai remarque que mon ordi tient mieux quand les economies d'energies de l'OS sont activees. Cela me rend sceptique vis-a-vis de l'article.

      L'article ne parle que du cpu. Pas du mode économie de l'écran, des disques dures, etc.
      • [^] # Re: Un bon test

        Posté par . Évalué à 2.

        Mais l'argumentation de l'article repose sur le fait que le CPU tourne à 100% de sa capacité tout le temps, ce qui est loin d'être le cas. Si le speed scaling ne nuit pas aux performances, à quoi sert cet article ?

        Mettre en place des politiques spéciales, c'est avant tout pour économiser l'énergie, pas pour ralentir l'exécution des tâches.

        Tant que l'OS est fluide, y a-t-il une raison pour faire tourner le CPU à 100% de sa fréquence ?

        Je ne comprend pas pourquoi utiliser powernowd, par exemple (ajustement de la fréquence du processeur en fonction de la charge), serait nuisible à l'environnement.

        Enfin, pour les politiques batterie/veille, je comprends encore moins. Limiter la consommation du processeur augmente forcément l'autonomie, mais je n'ai jamais entendu qu'elle diminuait les performances de façon critique (sauf si on utilise, évidemment, la dernière sortie dans la catégorie FPS 3D).

        Enfin, le ton est humoristique, mais je ne comprends pas exactement quels sont les programmes visés dont les auteurs devraient être considérés comme des parias :? J'avoue que ça me laisse perplexe.

        Mais, évidemment, tout le monde est d'accord pour dire qu'il faut utiliser le cpufreq ondemand. Mais j'ai l'impression que cet article enfonce une porte ouverte.
        • [^] # Re: Un bon test

          Posté par . Évalué à 3.

          > Mais, évidemment, tout le monde est d'accord pour dire qu'il faut utiliser le cpufreq ondemand.

          Tu te contre-dis.
          Ondemand ça veut dire 0 ou 100 % (de sa fréquence). Pas 30 ou 50 ou 75 %.
          Quand le cpu est utilisé (même très très peu de temps), il est utilisé à fond.
          • [^] # Re: Un bon test

            Posté par . Évalué à 1.

            Et quel est le rapport avec Fedora/RedHat ?
          • [^] # Re: Un bon test

            Posté par . Évalué à 2.

            Pardon, je pensais que ondemand adaptait simplement la vitesse du processeur à la charge.
            • [^] # Re: Un bon test

              Posté par . Évalué à 2.

              C'est ce qu'il me semblait aussi... et c'est ce que j'obtiens sur mon portable...
  • # Pas à l'utilisateur de deviner

    Posté par . Évalué à 3.

    l'article dit que vous serez pas plus malins que le processeur et le noyau.

    Décharger cette gestion sur l'utilisateur est un leurre.


    A ce propos, os X sur un macbook pro ne permet presque aucun choix sur la batterie, et en aucun cas proposer de varier la fréquence (ou tension) du cpu à l'utilisateur.

    A a juste de savoir s'il faut "éteindre ou pas le disque dur le plus souvent possible" (choix pas évident car le disque dur est le truc le plus lent à se réveiller, cela peut énerver l'utilisateur. c'est un échec technologique là.

    et diminuer un peu la lumière de l'écran ou pas.

    Tout le reste est masqué et géré selon le cas par l'os et le matériel.
    • [^] # Re: Pas à l'utilisateur de deviner

      Posté par . Évalué à 8.

      Pour un mac sous OS X c'est facile...

      Généraliser le modèle à des systèmes basés sur Linux avec des propos radicaux (oui j'ai bien conscience qu'ils sont humoristiques, ils n'en restent pas moins radicaux) comme le fait Matthew Garret est une erreur, car le système s'adresse selon le niveau aussi bien à des end users sur une plateforme matérielle (quasi) inconnue, auquel cas le système aura bien du mal à prendre les meilleurs décisions pour cause de méconnaissance de la machine et de son environnement (sauf dans un cas futur hypothétique ou les pilotes Linux auraient gagné d'un ordre de grandeur en qualité + les constructeurs de laptop mettraient parallèlement le paquet sur le support des systèmes à base de Linux par leur matos) et l'utilisateur peut réussir à obtenir de meilleurs résultats - d'autre part Linux peut aussi s'adresser à un ingé en train de concevoir un système embarqué auquel cas les capacités de mise au point de l'aspect économie d'énergie devront être le plus souple possible et facile d'accès.

      Bref son discours radical me fait un peu peur car je crains qu'il ne reste valable que sur un faible nombre d'ordinateurs portables high end et très modernes (et sous Linux...), dont probablement le sien.

      Ça représente vraisemblablement une très faible proportion de tous les systèmes Linux intéressés par les économies d'énergies (cad par les temps qui cours presque tous)

      Son raisonnement dépend en plus d'un trop grand nombre de variables et sa vérité actuelle peut donc s'inverser à tout moment, avec alors un risque de laisser les utilisateurs dans la merde s'il n'y a rien pour adapter facilement le soft dans ce cas là.
      • [^] # Re: Pas à l'utilisateur de deviner

        Posté par . Évalué à 1.

        Ok, mais ça n'explique pas pourquoi avec un Macbook Pro sous OSX (qui présente des options d'économies d'énergie et d'arrêt des disques) on tient 4 à 5 heures sur batterie sans souci, alors que sur le même ordi, on tient 2h30 avec Windows XP ou Linux.

        Si vraiment les programmes de gestion d'énergie ne servent à rien, clairement, ici je ne vois pas pourquoi...étant donné le résultat.
        • [^] # Re: Pas à l'utilisateur de deviner

          Posté par . Évalué à 2.

          Si vraiment les programmes de gestion d'énergie ne servent à rien, clairement, ici je ne vois pas pourquoi...

          L'article parle de variation de fréquence. La gestion d'énergie c'est aussi couper tout ce qui ne sert à rien (l'horloge voir le courant) c'est déjà complexe.

          "La première sécurité est la liberté"

      • [^] # Re: Pas à l'utilisateur de deviner

        Posté par . Évalué à 1.

        Mouaif.

        Il ne parle que du cpu.
        Il ne parle pas de l'écran (gros consommateur), de l'ajustement de la consommation de l'écran en fonction de l'utilisation du portable, de l'intéraction qu'il faut mettre en place avec l'utilisateur, etc.
        Idem pour les disques dures.
        Idem pour suspend.
        Etc.
        Le titre de la dépêche est trompeur ("Gestion de l'énergie : se dépêcher de ne rien faire"). Je ne peux pas croire que c'est ce que veut dire Matthew Garret (sauf peut-être pour le cpu).
        On est dans un domaine facilement mesurable et la doc sur la consommation du cpu en fonction de la fréquence, etc doit être disponible.
        Il suffit donc d'utiliser une calculatrice pour valides ou invalider ses propos.
        Je pense qu'il a fait ce boulot :-)
        Si au final il est claire que pour une même quantité de travail demandée au cpu il y a la même consommation d'énergie, il est un peu con de se faire chier avec la fréquence du cpu. Il est ridicule d'implémenter un truc qui n'apporte rien. D'autant plus qu'il y a beaucoup de boulot ailleurs et que les ressources sont limités.

        Est-il raisonnable d'implémenter quelques chose pour le cas où les technologies des cpu changent ?
        Je ne crois pas.
        Ajouter des "si machin ...", "si bidule ..." ne change rien. Il y a des choses qui doivent marcher et ne marchent pas encore de façon satisfaisante (l'hibernation par exemple). Ces dernières n'ont pas à être justifiées par des "si ...".
        • [^] # Re: Pas à l'utilisateur de deviner

          Posté par . Évalué à 6.

          Le titre de la dépêche est trompeur ("Gestion de l'énergie : se dépêcher de ne rien faire").

          C'est juste un jeu de mots. Aujourd'hui, on sait qu'il faut couper tout ce dont on a pas besoin. Le dilemme concerne les temps de réveilles, il faut donc bien choisir entre coupé les horloges et les alimentations des modules.

          Ensuite, il reste le problème des cpu eux-mêmes lorsqu'ils ont du boulot à faire.

          Le paradigme actuel de Linux est "Race to idle". D'où le titre. Qui veut dire en gros, "on se dépêche d'aller dans l'état idle", d'où le tickless, et autre powertop.

          L'autre paradigme est "spread to deadline" qui veut dire en gros, ralentir le cpu mais en garantissant une borne "temps réel". Cela consiste a diminuer la fréquence pour diminuer la tension. Typiquement, c'est d'avoir un "gouvernor" qui tend à avoir une charge de 1 au lieu d'une charge inférieur à 1.

          L'auteur sort les chiffres intel 24W à 50% de fréquence, 35W à 100%. Conclusion : baisser la fréquence est idiot, il vaut mieux tourner à 100% pour aller plus vite en idle (qui bouffe 5W).

          C'est vrai sous Intel, mais c'est pas gagné pour d'autre plateforme (system on chip).

          "La première sécurité est la liberté"

          • [^] # Re: Pas à l'utilisateur de deviner

            Posté par . Évalué à 2.

            > C'est juste un jeu de mots.

            Je n'avais pas compris :-)
            Si c'était "se dépêcher pour ne rien faire" j'aurais peut-être compris.
            Les bons jeux de mots ne saute pas aux yeux. Celui-ci est excellent.
    • [^] # Re: Pas à l'utilisateur de deviner

      Posté par (page perso) . Évalué à 1.

      > A ce propos, os X sur un macbook pro ne permet presque aucun choix
      C'est un peu la marque de fabrique de Mac quand même : ne laisser aucun choix à l'utilisateur, de toute façon, il est trop con :)

Suivre le flux des commentaires

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