Journal Noël, noël, un patch miraculeux !

Posté par  .
Étiquettes : aucune
31
17
nov.
2010
Phoronix vient de faire deux vidéos comparant les performances graphiques d'Ubuntu avec et sans l'application sur le noyau 2.6.37 d'un petit patch (un peu plus de 200 lignes) écrit par Mike Galbraith.

Ça poutre.

Comment ça marche ? Aucune idée, je ne mange pas de ce pain-là. Voici tout de même l'explication du monsieur :

Each task’s signal struct contains an inherited pointer to a refcounted autogroup struct containing a task group pointer, the default for all tasks pointing to the init_task_group. When a task calls __proc_set_tty(), the process wide reference to the default group is dropped, a new task group is created, and the process is moved into the new task group. Children thereafter inherit this task group, and increase it’s refcount. On exit, a reference to the current task group is dropped when the last reference to each signal struct is dropped. The task group is destroyed when the last signal struct referencing it is freed. At runqueue selection time, If a task has no cgroup assignment, it’s current autogroup is used.

Linus, quant à lui, trouve que c'est pas mal :

I'm also very happy with just what it does to interactive performance.
Admittedly, my "testcase" is really trivial (reading email in a
web-browser, scrolling around a bit, while doing a "make -j64" on the
kernel at the same time), but it's a test-case that is very relevant
for me. And it is a _huge_ improvement.

It's an improvement for things like smooth scrolling around, but what
I found more interesting was how it seems to really make web pages
load a lot faster. Maybe it shouldn't have been surprising, but I
always associated that with network performance. But there's clearly
enough of a CPU load when loading a new web page that if you have a
load average of 50+ at the same time, you _will_ be starved for CPU in
the loading process, and probably won't get all the http requests out
quickly enough.

So I think this is firmly one of those "real improvement" patches.
Good job. Group scheduling goes from "useful for some specific server
loads" to "that's a killer feature".

J'imagine que ça va tomber dans un PPA quelconque d'ici pas longtemps. D'ailleurs, je bave un peu.

L'article de Phoronix : http://www.phoronix.com/scan.php?page=article&item=linux(...)

Et chez Korben : http://www.korben.info/un-patch-qui-boost-les-performances-d(...)

  • # dommage

    Posté par  . Évalué à 5.

    il ne sera pas integre au noyau avant 2.6.38 :(

    • [^] # Re: dommage

      Posté par  . Évalué à 3.

      Si tu es aventureux tu pourras patcher ton noyau à la main un peu avant.

      • [^] # Re: dommage

        Posté par  . Évalué à 10.

        oui mais je peux pas regarder de videos en meme temps... Ah la la c'est le serpent qui se mord la queue :)

      • [^] # Re: dommage

        Posté par  . Évalué à 2.

        Justement, personne n'a la marche à suivre pour debian ? J'ai déjà compilé mon noyaux, mais j'ai toujours fait face à des problèmes d'usage après (je ne sais plus de quelle nature d'ailleurs, mais je sais que je n'ai pas gardé longtemps mon noyaux perso).

    • [^] # Re: dommage

      Posté par  . Évalué à -1.

      Quelqu'un sait pourquoi il ne peut pas être intégré officiellement au 2.6.37 alors que son développement ne vient que de commencer (on est seulement en rc2) ?
      Une question de fil d'attente ? Il y a déjà trop de patches à intégrer/vérifier, il n'y a aucune chance de l'intégrer pour la 2.6.37 ?

      • [^] # Re: dommage

        Posté par  . Évalué à 6.

        Il faut respecter la fenêtre de merge. Et c'est temps ci, Linus est assez strict là dessus. Et je suppose que le patch doit nécessiter quelques vérifications approfondies...

      • [^] # Re: dommage

        Posté par  . Évalué à 7.

        Les différentes release candidates, ça a pour finalité de tester en profondeur les nouvelles fonctionnalités et de traquer les régressions. Tu conviendras donc qu'ajouter du code ( et donc très possiblement des bogues ) en plein milieu de ce processus n'est pas la meilleure chose à faire. :-)

  • # Bravo!

    Posté par  . Évalué à 2.

    Comme quoi, les meilleures améliorations ne sont pas forcément les plus complexes. Même un simple petit patch de 233 lignes arrive à impressionner Linus Torvalds :)

    • [^] # Re: Bravo!

      Posté par  . Évalué à 10.

      Oui, en même temps, une idée peut être complexe à imaginer et facile à coder....

      Et pour info, apparemment, c'était une idée de Linus à l'origine. C'est le résultat et la manière de le coder qui l'a impressionné.

    • [^] # Re: Bravo!

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

      Les plus courtes sont (presque) toujours les meilleures :)

      • [^] # Re: Bravo!

        Posté par  . Évalué à 10.

        j'ai presque envie de faire une blague à base de "ta femme" et "pour te rassurer", mais je passerais outre :)

        • [^] # Re: Bravo!

          Posté par  . Évalué à 1.

          Prétérition spotted.

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Bravo!

          Posté par  . Évalué à 1.

          En fait il voulait raconter la blague du nain de la personne de petite taille qui a 14 enfants.

          • [^] # Re: Bravo!

            Posté par  . Évalué à 2.

            Elle est courte mais elle est bonne !

  • # À qui profite le patch ?

    Posté par  . Évalué à 5.

    Ce patch permet une meilleure répartition de charge en cas d'utilisation d'applications fortement multi-thread sur une machien de bureau. Mais ça vous arrive souvent de compiler le noyau en make -j 64 avec glxgears dans un coin tout en regardant une vidéo haute définition ? Chez moi ces trois activités s'excluent mutuellement.

    • [^] # Re: À qui profite le patch ?

      Posté par  . Évalué à 10.

      Ben ça peu être utile le jour où l'envie te prendra d'ouvrir Firefox et OOo durant la même session.

      Mais bon, c'est un cas extrême, il faut l'avouer.

      • [^] # Re: À qui profite le patch ?

        Posté par  . Évalué à 2.

        D'après l'explication ci-dessous, c'est justement un cas de figure qui n'est pas concerner par ce patch.

        « 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: À qui profite le patch ?

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

        Perdu, t'es bloqué par les I/O, pas par le CPU dans ce cas là, mais la blague était drôle :-)

        • [^] # Re: À qui profite le patch ?

          Posté par  . Évalué à 4.

          Pas vraiment justement avec le make -j, j'ai rarement des compilations bloquées par l'I/O. Il faut dire que j'ai aussi que ext4 à l'air de bien se débrouiller quand il y a assez de RAM dispo.

          DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: À qui profite le patch ?

      Posté par  . Évalué à 8.

      Le but du "make -j 64" est de charger facilement le système à moindre coût (pleins de processus et pleins d'accès disque). La vidéo et le bon vieux glxgears, eux, servent à avoir un retour visuel.

      Ça serait certes pas mal d'avoir de vraies stat (temps de commutation de tâches, latence dans des IPC) mais à défaut d'en avoir, on a un exemple plutôt parlant de l'amélioration.

      Dans la vraie vie, l'utilisateur qui fait du web+mail+zik+bureautique ne verra pas vraiment de différences mais celui qui fait de la synthèse d'image, du montage vidéo ou de la simulation, il sera content de ne pas voir son environnement ramer pendant qu'il fait autre chose.

      Côté serveur, ça devrait permettre une meilleure réactivité lorsque la charge système est élevée.

      • [^] # Re: À qui profite le patch ?

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

        Même avec du web/mail/zic sur un netbook double coeur (qui arrivent en masse), ca devrait pouvoir être visible, surtout si la musique passe par Deezer avec du Flash qui clignote.

        • [^] # Re: À qui profite le patch ?

          Posté par  . Évalué à 2.

          En effet, j'avais pas ce type de machines en tête lors de mon commentaire précédent. On peut aussi penser aux machines de plus petit gabarit qui utilise(ront) des ARM double-coeur.

    • [^] # Re: À qui profite le patch ?

      Posté par  . Évalué à 5.

      Je suis utilisateur de Gentoo sur une machine plus toute récente, donc ça m'arrive :)

      DLFP >> PCInpact > Numerama >> LinuxFr.org

      • [^] # Re: À qui profite le patch ?

        Posté par  . Évalué à 3.

        J'utilise Gentoo depuis 5 ans sur la même machine (celle devant moi en ce moment) et ça ne m'est pourtant jamais arrivé.

    • [^] # Re: À qui profite le patch ?

      Posté par  . Évalué à 3.

      Pendant mes compilation, j'utilise en général Firefox pour passer le temps. Et vu la lourdeur du JS de certaines pages, multiplié par une bonne cinquantaines d'onglet, ouais, ça peut faire du bien au lancement d'une vidéo Youtube.

      • [^] # Re:Àqui profite le patch ?

        Posté par  . Évalué à 1.


        s/JS de certaines pages/Firefox

      • [^] # Re: À qui profite le patch ?

        Posté par  . Évalué à 2.

        Si tu compiles en -j 1 (ou -j nombre_de_cœurs_de_la_machine), ça ne fera rien de particulier.

        Quant à firefox, il ne gère pas ses onglets dans des processus séparés donc aucun effet non plus.

        • [^] # Re: À qui profite le patch ?

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

          Ben si ça aura un effet sur firefox, car même si ce dernier ne tourne que dans un seul processus, ce processus aura plus de temps à disposition. A la limite si firefox est tout seul dans son groupe et que ton make -j 64 est dans un autre groupe, ça donne du 50% firefox 50% make.
          Alors que pré-patch, ça donne 1/65 firefox, 1/65 pour tous les autres processus du make.

          • [^] # Re: À qui profite le patch ?

            Posté par  . Évalué à 3.

            Oui dans ce cas tu as raison sûr, sauf que personne ne compile vraiment en -j 64 (la valeur recommandée c'est -j nombre_cœurs+1)

            [et même si ce n'est pas exactement pareil, au cas où tu veux vraiment faire make -j 64, tu peux toujours le mettre en nice -n 19]

            • [^] # Re: À qui profite le patch ?

              Posté par  . Évalué à 4.

              Pour une compilation je ne sais pas, mais il faut noter que pour une application qui demande du calcul que je fais tourner avec un nombre de thread égal au nombre de processeurs (on enlève le +1 parce qu’il n’y a pas d’I/O) la lantence induite sur Gecko est perceptible, et le renice nécessaire. Donc je vois plutôt cette amélioration, de ce que j’en sais, comme un confort supplémentaire, sauf ceux qui ne connaissent pas (re)nice et qui vont y voir des performances accrues…

    • [^] # Re: À qui profite le patch ?

      Posté par  . Évalué à 2.

      Sur un linux en desktop, un virtualbox qui tourne + un firefox et on le sent passer mine de rien :)

      A votre avis, le patch sera profitable sur ce type d'utilisation ? (idem avec kvm j'imagine).

    • [^] # Re: À qui profite le patch ?

      Posté par  . Évalué à 1.

      Mais je fais ça tous les jours :)

  • # Testé et approuvé ;)

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

    Le .37 apportait déjà pas mal car on gagnait vraiment en fluidité sous forte charge mais là, avec ce patch en plus, c'est une tuerie :)

    Sur mon liveusb, c'est étonnamment fluide ;)

    == Explications (théorie) ==
    Pour l'explication technique, c'est pas bien compliqué (c'est une supposition qui correspond bien au nom du patch).

    Soit X le nombre de processus sur le système.
    Sans le patch, chaque processus recevra un minimum de 100/X % du processeur.

    Le problème, c'est que quand on compile avec 64 gcc, on diminue vachement le temps processeur restant pour les autres applications (qui ont besoin d'un pic de CPU, mais pas longtemps).

    Donc, plutôt que d'allouer le temps processeur en fonction du nombre de processus, ce temps processeur est alloué en fonction des groupes.

    Si on a un groupe GUI et un groupe compilation, 50% du temps processeur ira à la GUI et 50% ira à la compilation. Comme le groupe GUI n'a pas besoin de tout ça, l’excédant part dans les groupes qui en ont besoin :)

    Et voilà comment on augmente la réactivité générale sans vraiment perdre en performance :)

    PS: Il semblerait que les groupes soient définis en fonction du TTY depuis lequel il a été lancé. Comme la GUI est sur le TTY7 et que les consoles sont dans /dev/pts/, les 2 sont dans 2 groupes séparés, et on a donc un ordonnancement plus juste.

    Je me demande comment le système réagira en cas de bomb fork avec ce patch, faudra que je teste à l'occaz.

    • [^] # Re: Testé et approuvé ;)

      Posté par  . Évalué à 2.

      Donc si j’ai bien compris c’est juste une façon différente de calculer la priorité des processus, du coup il n’y a pas de différence avec un simple « nice » des processus fortement demandeur si j’ai bien compris. Donc c’est une amélioration à relativiser si tel est son fonctionnement.

      • [^] # Re: Testé et approuvé ;)

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

        Mouais, dans un sens, tu as raison, mais bonne chance si tu veux émuler ça avec nice car y'a pas toujours 64 threads de compilations, des fois, tu en auras 3 et des fois 25.

        C'est plus propre comme ça je trouve!

      • [^] # Re: Testé et approuvé ;)

        Posté par  . Évalué à 4.

        Dans l'absolu, c'est le même principe, sauf que là les priorités sont ajustées automatiquement, alors qu'avec nice il faut les fixer manuellement, et la valeur idéale dépend du nombre de processus (par groupe et total). De plus, une niceness élevée implique un time slice faible, et donc une perte de CPU (context switch, ordonnencement). Mais effectivement, on devrait pouvoir arriver plus ou moins au même résultat avec un nice 19...

    • [^] # Re: Testé et approuvé ;)

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

      Ca voudrais donc dire qu'il suffirait de lancer une appli graphique à partir d'une console virtuelle pour qu'elle appartienne à un groupe particulier (voir qu'elle soit toute seule dans ce groupe) et bénéficie de son quota de temps à elle...?

      Quid du serveur X ?

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: Testé et approuvé ;)

        Posté par  . Évalué à 1.

        J'imagine que le serveur X est dans le groupe du tty7 et que toutes les applis qui dépendent
        de X sont dans ce groupe. On discutait de ça justement aujourd'hui avec un collègue qui relativisait la porter de ce patch.

        Si tu lances une console, ça ne serait pas dans tty7. Du coup, c'est intéressant pour les gens qui compilent beaucoup mais pas forcément pour monsieur tout le monde.

        • [^] # Re: Testé et approuvé ;)

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

          Moi je ne serais pas si pessimiste que ça à son égare. L'utilisation des cgrroups se répand de plus en plus et je pense qu'il est possible qu'à moyen terme on trouve des GUIs qui permettent de controler quelles applications vont dans quel groupe. A fortiori avec ce patch qui crée un interêt encore plus grand aux cgroups :p

          • [^] # Re: Testé et approuvé ;)

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

            Ça serait cool d'avoir des outils en CLI et en GUI pour gérer ça facilement, oui !

          • [^] # Re: Testé et approuvé ;)

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

            Dans le thread sur la LKML certains rappellent que les cgroups ne sont pas neutres au point de vue des perfs (ça bouffe de la ressource). Donc est-ce qu'il vaut mieux activer les cgroups et faire perdre un peu de perfs à tous le monde pour qu'un petit groupe de personnes ayant des besoins très spécifiques profitent d'une bien meilleure réactivité ?
            Il faudra sans doute pas mal de tests et de benchs pour voir les compromis à faire.

            • [^] # Re: Testé et approuvé ;)

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

              À mon avis pour les distributions desktop y a même pas à réfléchir pour intégrer un système de ce type. ENFIN une chance que la souris ne rame plus quand une appli alakon fout le dawa.

              Pour ce qui est des distributions serveur par exemple... bah on peut partir du principe que l'admin saura choisir une politique adaptée à ses besoins (bon, en vrai, c'est faux, mais tant pis pour lui).

              • [^] # Re: Testé et approuvé ;)

                Posté par  . Évalué à 6.

                ENFIN une chance que la souris ne rame plus quand une appli alakon fout le dawa.

                Sauf que ce patch ne change rien à ce cas : sans le patch, tu as ton appli qui "fout le dawa", tu lances un autre processus, chacun aura 50% du temps processeur (sauf s'il y a une niceness). Avec le patch, chacun aura aussi 50% du temps processeur. Le patch crée implicitement des groupes en se basant sur le tty associé au processus, c'est tout. Donc à moins que ton processus n'ait une dizaine de threads qui "foutent le dawa", ça ne va rien changer.
                Pour ce qui est de l'inclusion, on peut imaginer que cette option soit activée en mode CONFIG_PRREMPT (low latency desktop).
                Je n'ai jamais eu de problème de latence (sur un desktop) à cause d'un processus qui monopolise le CPU.
                Lorsqu'on a des latences observables, c'est très rarement l'ordonnenceur qui est en cause, mais beaucoup plus souvent l'ordonnenceur d'E/S ou une consommation trop importante de mémoire, et donc utilisation du swap.

                • [^] # Re: Testé et approuvé ;)

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

                  Mon commentaire était un peu plus général, en réponse à l'argument de patrick_g : « les cgroups consomment, donc est-ce un gain de les utiliser ? ». Je reconnais que dans le contexte d'un journal qui parle de ce patch en particulier il est normal que tu y répondes dans ledit contexte :-) Mais plus généralement, si ce patch peut en inspirer d'autres, ou inspirer un système complet pour tirer plus partie des cgroups dans un contexte desktop...

            • [^] # Re: Testé et approuvé ;)

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

              Remarque très pertinente.

              En l'état la question se pose, mais on peut imaginer que les distributions fassent des groupes pour les applications graphiques gourmandes (telles que les outils de recherche sur disque dur). Dans ce cas là, tout le monde aura intérêt à utiliser les cgroups.

            • [^] # Re: Testé et approuvé ;)

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

              Les cgroups sont activés sur android, et je fais vaguement confiance à google en ce qui concerne les perfs utilisateurs.

    • [^] # Re: Testé et approuvé ;)

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

      Il faut quand même préciser que cette notion de groupes était déjà là avant ce patch. Tout ce que ce patch fait c'est répartir les processus dans des groupes par tty. Ce qui explique pourquoi il est si court.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # XDCMP et FreeNX

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

    Selon vous, ce patch sur un serveur XDCMP d'applis desktop, ça donne quoi?
    à priori un seul tty est partagé, la charge venant principalement d'applications en gui, l'affichage ne devrait pas être fluidifié (cas d'un système massivement multi-utilisateur).
    Me gourre-je, et où le cas échéant?

    Pour les sessions shadow de FreeNX, y'aura-t-il une fluidification? Je pense que cette question est un peu vaste, mais j'ai du mal à apréhender le truc.

    • [^] # Re: XDCMP et FreeNX

      Posté par  . Évalué à 1.

      Et pour plusieurs instances de mplayer/mencoder/gstreamer simultanées ? :)

Suivre le flux des commentaires

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