Une solution au problème de consommation du noyau Linux

Posté par  . Modéré par Nÿco. Licence CC By‑SA.
Étiquettes :
52
17
nov.
2011
Linux

Depuis sa version 2.6.38, le noyau Linux est atteint d’une régression sur la consommation d’énergie. Sur certaines configurations matérielles, la consommation pouvait augmenter jusqu’à 25 %.

Suite à différents tests, notamment de la part de Michael Larabel de Phoronix (il s’en est d’ailleurs largement entretenu dans beaucoup d’articles), il a été identifié que c’était à la suite d’un correctif du noyau que la régression était apparue. La norme PCI Express a introduit l’ASPM (Active State Power Management), un moyen pour diminuer la consommation des périphériques, mais qui n’est pas toujours pris en charge.

C’est le BIOS qui est censé exposer au noyau la configuration, seulement ce n’est pas toujours fait, car les fabricants passent outre avec leur pilote Windows et ne s’en tracassent pas le moins du monde. Avant le noyau 2.6.38, l’option était activée sur toutes les configurations, mais comme cela peut poser de sérieux problèmes, la vérification du BIOS a été introduite… Et là, c’est le drame !

Un patch a été créé en se basant sur des explications de Microsoft concernant l’implémentation de l’ASPM dans Windows Vista, afin de détecter si réellement le système peut activer cette option sans risque. Et ça a l’air de fonctionner. Comme la fenêtre d’intégration pour le noyau 3.2 a été fermée, il faudra attendre le 3.3 avant de voir ce patch arriver.

Aller plus loin

  • # Fin du réchauffement climatique…

    Posté par  . Évalué à 10.

    … les manchots vont cesser de faire fondre la banquise.

    \o/

  • # Déjà vu ?

    Posté par  (Mastodon) . Évalué à 3.

    Il n'y a pas un air de "déjà vu" dans cette histoire ?

    C'est une nouvelle surconsommation ? Ou est-ce que la cause n'avait pas été trouvée ?

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Déjà vu ?

      Posté par  . Évalué à 10.

      C'est la solution propre qui n'avait pas été trouvée. On pouvait utiliser aspm=force mais on revenait avec les problèmes pré-2.6.38. Maintenant, on a une solution qui marche pour détecter si le matériel le supporte ou pas et on peut donc l'utiliser sans risque.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Déjà vu ?

        Posté par  . Évalué à 10.

        Plus exactement :
        - avant on le mettait à tous les coups, du coup le matériel bloquait sur certaines machines
        - après on a dit qu'on ne le mettait que si le matériel l'annonce, du coup on consommait plus
        - dans le noyau 3.3, on ne le désactive que dans les cas où Windows 6.X le désactive, puisque c'est comme ça que les fabricants testent leur BIOS.

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

  • # Manchot bleu

    Posté par  . Évalué à 3.

    J'adore le : << Un patch a été créé en se basant sur des explications de Microsoft >>

    • [^] # Re: Manchot bleu

      Posté par  . Évalué à -3.

      Oui c'est très marrant de voir que Windows créée une situation de merde en forçant les constructeurs à ne pas respecter les standard et après vient expliquer aux dev linux comment faire de même et que ces cons au lieu de gueuler appliquent bien gentillement les règles M$.

      Comme quoi Linux et Windows vont bien finir par converger et pas vers le meilleur...

      • [^] # Re: Manchot bleu

        Posté par  . Évalué à 10.

        D'après ce que j'ai compris, c'est surtout la faute aux constructeurs, qui ont fait de la merde en laissant le BIOS dire n'importe quoi. Je ne vois nulle part de mention comme quoi MS à forcé les constructeurs à faire de la merde…

        • [^] # Re: Manchot bleu

          Posté par  . Évalué à 9.

          Je dirais s/forcé/permis/.
          Car si Microsoft était resté droit dans ses bottes, les fabricants se seraient alignés.
          Seulement Microsoft a tout intérêt à complexifier la situation, tout en ne donnant pas trop d'informations (raté sur ce coup là ?).
          C'est la même chose pour APCI.

          • [^] # Re: Manchot bleu

            Posté par  . Évalué à 1.

            bof, c'est plus de la flemme et d'envie des constructeurs qui se contentent de faire, "windows, ca marche, ok, on produit".

            Après, la PDM des systèmes libres est évidement un handicap pour que les constructeurs s'assurent d'un meilleur fonctionnement.

  • # Enfin !

    Posté par  (site web personnel) . Évalué à 7.

    Mon netbooke LDLC Mercure (Clevo M1111 pour les intimes) est affecté par ce bug. Le BIOS est pourri car les développeurs ont utilisé le compilateur Microsoft, plus permissif que celui d'Intel. J'ai tenté le aspm=force, mais sans grand résultat sur l'autonomie, et des blocages plus fréquents en retour de veille.

    J'avais donc suivi la procédure: désassemblé les tables du BIOS, corrigé les erreurs de compilation apparaissant avec le compilateur Intel... Et là c'est le drame. La fonctionnalité permettant de simplement indiquer un fichier externe correspondant à la table DSDT à utiliser a été retirée pour des raisons de sécurité, la politique actuelle étant que ce type de choses doit être corrigé dans le kernel, et pas en local chez les utilisateurs. J'ai eu la flemme de recompiler un kernel ou bidouiller mon initrd pour ça...

    Au final, savoir que l'utilisateur lambda qui n'a pas forcément de connaissances poussées va pouvoir bénéficier de ces avancées est très positif. Ce qui l'est moins, c'est tout le temps qui s'est écoulé entre la détection du problème et sa correction, et ensuite sa propagation dans les différentes distributions Linux. Du coup, un problème de ce genre impacte les utilisateurs pendant facilement un an, alors que le libre a la réputation d'être réactif. Il faut encore progresser...

    • [^] # Re: Enfin !

      Posté par  . Évalué à -7.

      wow désassemblé rien que ça :o
      compilateur? tu ne veux pas dire assembleur?
      à moins que ton bios soit fait en C?

    • [^] # Re: Enfin !

      Posté par  (site web personnel) . Évalué à 1.

      J ai essaye aussi sur un laptop lenovo g470 :

      http://rzr.online.fr/q/lenovo

      aspm=force : n a rien donne'

      idem en fixant la dsdt ...

      Le symptome majeur est que le ventilo tourne kazi tout le temps (meme en idle)

      La question est comment savoir que cela fonctionne egalement sous windows ?

      j ai egalement quelques pistes :

      http://rzr.online.fr/q/aspm

      N hesitez pas a me contacter si vous voulez bidouiller ensemble

      gpg:0x467094BC

      • [^] # Re: Enfin !

        Posté par  . Évalué à -9.

        Ya pas un parametre de temperature pour les ventilos?
        A l'epoque ou j'avais tente de faire marcher linux sur un ibook g3, fallait monter la temperature de declenchement des ventilos qui etait ridiculement basse (genre 10-20 degres de moins que les params d'apple).

        Bon apres si la sonde temperature est pas fiable, ca peut expliquer le pb.

        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

    • [^] # Re: Enfin !

      Posté par  . Évalué à 1.

      C'est devenu une procédure courante chez les utilisateurs de hackintosh.
      "OSX has an incomplete ACPI implementation which supports only a subset of DSDT."
      http://ihackintosh.blogspot.com/2008/12/what-is-kext-kernel-dsdt-smc-rtc-efi.html

  • # Est ce que ce ne serait pas le moment de pousser un BIOS libre ?

    Posté par  . Évalué à 8.

    Est ce qu'un BIOS libre ne permettrait pas de régler ce problème une fois pour toutes, pour tous les matériels ?
    (je précise que je n'y comprends rien, je ne sais pas si ces BIOS fonctionnent, sur quelles architecture, ni quel boulot ça représenterait de régler le problème dans le BIOS, je me dis juste que voilà un argument en faveur d'un BIOS libre)

Suivre le flux des commentaires

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