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 Albert_ . Évalué à 5.
[^] # Re: dommage
Posté par Lutin . Évalué à 3.
[^] # Re: dommage
Posté par Albert_ . Évalué à 10.
[^] # Re: dommage
Posté par Anonyme . Évalué à 2.
[^] # Re: dommage
Posté par Tom . Évalué à 4.
http://www.kroah.com/lkn/
[^] # Re: dommage
Posté par dyno partouzeur de drouate . Évalué à 8.
Attendre 5 ans ?
[^] # Re: dommage
Posté par Jarvis . Évalué à -1.
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 Spack . Évalué à 6.
[^] # Re: dommage
Posté par Vivien MOREAU . Évalué à 7.
# Bravo!
Posté par Spyhawk . Évalué à 2.
[^] # Re: Bravo!
Posté par cosmocat . Évalué à 10.
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 shinobufan (site web personnel) . Évalué à 4.
[^] # Re: Bravo!
Posté par Prae . Évalué à 10.
[^] # Re: Bravo!
Posté par Grunt . Évalué à 1.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Bravo!
Posté par Kerro . Évalué à 1.
[^] # Re: Bravo!
Posté par Moogle . Évalué à 2.
# À qui profite le patch ?
Posté par JGO . Évalué à 5.
[^] # Re: À qui profite le patch ?
Posté par vladislav askiparek . Évalué à 10.
Mais bon, c'est un cas extrême, il faut l'avouer.
[^] # Re: À qui profite le patch ?
Posté par claudex . Évalué à 2.
« 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 liberforce (site web personnel) . Évalué à 1.
[^] # Re: À qui profite le patch ?
Posté par DLFP est mort . Évalué à 4.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: À qui profite le patch ?
Posté par Rémi Hérilier . Évalué à 8.
Ç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 David Tschumperlé (site web personnel) . Évalué à 4.
[^] # Re: À qui profite le patch ?
Posté par Rémi Hérilier . Évalué à 2.
[^] # Re: À qui profite le patch ?
Posté par DLFP est mort . Évalué à 5.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: À qui profite le patch ?
Posté par JGO . Évalué à 3.
[^] # Re: À qui profite le patch ?
Posté par Vlobulle . Évalué à 3.
[^] # Re:Àqui profite le patch ?
Posté par daimrod . Évalué à 1.
s/JS de certaines pages/Firefox
[^] # Re: À qui profite le patch ?
Posté par JGO . Évalué à 2.
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 Jux (site web personnel) . Évalué à 4.
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 JGO . Évalué à 3.
[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 nicolas . Évalué à 4.
[^] # Re: À qui profite le patch ?
Posté par ulver . Évalué à 2.
A votre avis, le patch sera profitable sur ce type d'utilisation ? (idem avec kvm j'imagine).
[^] # Re: À qui profite le patch ?
Posté par totof2000 . Évalué à 1.
# Testé et approuvé ;)
Posté par Martin Peres (site web personnel) . Évalué à 10.
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 nicolas . Évalué à 2.
[^] # Re: Testé et approuvé ;)
Posté par Martin Peres (site web personnel) . Évalué à 3.
C'est plus propre comme ça je trouve!
[^] # Re: Testé et approuvé ;)
Posté par neologix . Évalué à 4.
[^] # Re: Testé et approuvé ;)
Posté par Albert_ . Évalué à 4.
Le probleme pour les utilisateurs de ubuntu c'est que les cgroup semble etre desactive dans leur noyau onc il va falloir attendre. Toutefois si l'effet se confirme bien je soupconne que l'on va voir apparaitre des kernel patche pour toutes les distribs tres bientot.
http://www.omgubuntu.co.uk/2010/11/linux-to-get-a-lot-faster(...)
[^] # Re: Testé et approuvé ;)
Posté par Albert_ . Évalué à 3.
http://blog.glock.co.za/cgroup-user-space-speed-patch
[^] # Re: Testé et approuvé ;)
Posté par lolop (site web personnel) . Évalué à 3.
Quid du serveur X ?
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Testé et approuvé ;)
Posté par dest . Évalué à 1.
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 Ph Husson (site web personnel) . Évalué à 6.
[^] # Re: Testé et approuvé ;)
Posté par Martin Peres (site web personnel) . Évalué à 2.
[^] # Re: Testé et approuvé ;)
Posté par patrick_g (site web personnel) . Évalué à 5.
Il faudra sans doute pas mal de tests et de benchs pour voir les compromis à faire.
[^] # Re: Testé et approuvé ;)
Posté par Sufflope (site web personnel) . Évalué à 3.
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 neologix . Évalué à 6.
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 Sufflope (site web personnel) . Évalué à 2.
[^] # Re: Testé et approuvé ;)
Posté par Martin Peres (site web personnel) . Évalué à 5.
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 Ph Husson (site web personnel) . Évalué à 4.
[^] # Re: Testé et approuvé ;)
Posté par Krunch (site web personnel) . Évalué à 6.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# XDCMP et FreeNX
Posté par legranblon (site web personnel) . Évalué à 2.
à 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 kalonji . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.