[Kernel Patch] sched_autogroup

Reconnaissance et configuration du matériel / kernel linux
Avatar de l’utilisateur
ed0c
Chu Ko Nu
Messages : 327
Inscription : mer. 24 mars 2010, 10:02

[Kernel Patch] sched_autogroup

Message par ed0c » mer. 17 nov. 2010, 15:24

http://www.phoronix.com/scan.php?page=a … 2637_video

Miraculeux ce patch sur le papier, et en vidéo..
Quelqu'un connait ?
Quelqu'un a testé..?

La version pour le kernel 2.6.36 : http://pavlinux.ru/krnl/sched_autogroup ... .patch.bz2

Le thread sur le forum anglais d'archlinux : https://bbs.archlinux.org/viewtopic.php?id=108516

Avatar de l’utilisateur
ph11
Daikyu
Messages : 94
Inscription : mer. 28 janv. 2009, 21:35
Contact :

Re: [Kernel Patch] sched_autogroup

Message par ph11 » mer. 17 nov. 2010, 21:52

En train de tester. J'ai tout de même des mini-freezes que je n'avais pas avant, mais c'est peut-être du à autre chose.
Je ne saurais pas dire si ça apporte quelque chose, vu qu'il faut passer en testing pour l'utiliser.

Code : Tout sélectionner

pacman -U http://pkgbuild.com/~ioni/kernel26-2.6.36-3-i686.pkg.tar.xz
pacman -U http://pkgbuild.com/~ioni/kernel26-2.6.36-3-x86_64.pkg.tar.xz

Avatar de l’utilisateur
mum1989
Chu Ko Nu
Messages : 454
Inscription : sam. 11 oct. 2008, 23:19

Re: [Kernel Patch] sched_autogroup

Message par mum1989 » mer. 17 nov. 2010, 23:14

passer en testing ????? oh purée javais pas fait gaffe on est qu'en 2.6.35 :(

sinon une idée sur l'apport ici :
http://www.tux-planet.fr/la-noyau-linux ... nt-ou-pas/

Je m'interroge sur l'apport du patch je comprend pas grand chose.

sur pc inpact voici ce qu'un Inpactient avait apparemment compris et ça semble juste :
Et pour ceux qui critique l'ordonnanceur pré patch, il faut aussi savoir que le patch utilise les cgroup, cgroup étant une extension prévu de l'ordonnanceur pour modifier la politique d'ordonnancement. Les cgroups étaient surtout utilisé pour améliorer les perfs des serveurs aujourd'hui.
Le patch "ne fait" qu'automatiser la création de ces groupes de taches afin d'améliorer l'expérience utilisateur lambda.

Donc au contraire cela montre la puissance de l'ordonnanceur et ses possibilités de modifier son comportement selon différent cas d'utilisation.

Avatar de l’utilisateur
chipster
Maître du Kyudo
Messages : 2063
Inscription : ven. 11 août 2006, 22:25
Localisation : Saint-Étienne (42)
Contact :

Re: [Kernel Patch] sched_autogroup

Message par chipster » jeu. 18 nov. 2010, 09:42

J'ai pas mal cherché et un pote m'a mis sur la voie. Ce patch est intéressant à partir du moment où on lance les programmes dans un TTY. Pour un serveur c'est super intéressant mais pour un utilisateur Desktop c'est tout sauf inutile à moins que vous aimiez lancer tous vos programmes dans un TTY, ...
Ce que j'ai déjà dit dans un poste similaire, le meilleur scheduler à ce jour reste de loin BFS
Je redis, -j 64 mais lol c'est n'importe quoi et ça ne sert strictement à rien (ou alors il faut m'expliquer) :D

Avatar de l’utilisateur
chipster
Maître du Kyudo
Messages : 2063
Inscription : ven. 11 août 2006, 22:25
Localisation : Saint-Étienne (42)
Contact :

Re: [Kernel Patch] sched_autogroup

Message par chipster » jeu. 18 nov. 2010, 09:48

Voici des tests intéressant :
http://lkml.org/lkml/2010/10/19/123 celui qui va modifier CFS et la ligne en question qui nous intéresse est
kernel/sched_tty.c | 128 ++++++++++++++++++++++++++++++++++++++++++++++++++
Regardez bien sched_TTY

http://ck.kolivas.org/patches/bfs/bfs35 ... eads.patch BFS donc Kolivas avec la ligne qui nous intéresse
kernel/sched_bfs.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++----

Avatar de l’utilisateur
chipster
Maître du Kyudo
Messages : 2063
Inscription : ven. 11 août 2006, 22:25
Localisation : Saint-Étienne (42)
Contact :

Re: [Kernel Patch] sched_autogroup

Message par chipster » jeu. 18 nov. 2010, 09:54

La réponse de Kolivas sur son blog : http://ck-hack.blogspot.com/

Avatar de l’utilisateur
bennyboy
archer de cavalerie
Messages : 154
Inscription : dim. 12 oct. 2008, 20:36

Re: [Kernel Patch] sched_autogroup

Message par bennyboy » jeu. 18 nov. 2010, 11:46

C'est vrai que le -j64 trop fort quoi!!!!
Mon wiki
Mon Github
T'es tellement no-life que t'aimerais être un PC pour redémarrer ta vie en mode sans échec !

Avatar de l’utilisateur
chipster
Maître du Kyudo
Messages : 2063
Inscription : ven. 11 août 2006, 22:25
Localisation : Saint-Étienne (42)
Contact :

Re: [Kernel Patch] sched_autogroup

Message par chipster » jeu. 18 nov. 2010, 12:42

Après quelques lectures à droite à gauche, il semblerait que le patch CFS ralentisse de manière notable l'utilisation normal donc hors TTY :|

bailchanis
Daikyu
Messages : 71
Inscription : mar. 08 déc. 2009, 02:15

Re: [Kernel Patch] sched_autogroup

Message par bailchanis » jeu. 18 nov. 2010, 14:39

chipster a écrit : -j 64 mais lol c'est n'importe quoi et ça ne sert strictement à rien (ou alors il faut m'expliquer) :D

tu dis que c'est n'importe quoi, parce qu'il est recommandé un peu partout de prendre -j N où N est le nombre de coeurs ?

Quand je compilais mon système sur un Q6600 j'avais des gains en perf jusqu'à 15/17 (avec un gain vraiment substantiel par rapport à la reco théorique du -j 3 : plusieurs minutes de gagnées sur la compilation d'OpenOffice), du coup 64 pour un i7 ça ne me choque pas particulièrement.

Si la pratique montre une chose qui défie la théorie ce n'est pas l'expérience que je vais qualifier de n'importe quoi :wink:

Avatar de l’utilisateur
chipster
Maître du Kyudo
Messages : 2063
Inscription : ven. 11 août 2006, 22:25
Localisation : Saint-Étienne (42)
Contact :

Re: [Kernel Patch] sched_autogroup

Message par chipster » jeu. 18 nov. 2010, 16:39

des perfs jusqu'à 15/17, ça veut dire quoi et tu l'as mesuré comment ?
-j3 car tu avais 3 cores ?

Je dis que c'est n'importe quoi car je sais à quoi ça sert et comment ça fonctionne, pas simplement parce que je l'ai lu quelque part et ça change beaucoup de choses. C'est aussi pour ça que j'ai rajouté qu'il fallait m'expliquer car j'attends les explications :)
Les explications sont données entre autres sur le blog de CK et si tu cherches dans le lien donnée par mum1989, tu trouveras la même chose. Réfléchie aussi à qu'est-ce qu'il se passe quand tu fais une telle déclaration. Les 64 threads créés, ils finissent où ? :D

bailchanis
Daikyu
Messages : 71
Inscription : mar. 08 déc. 2009, 02:15

Re: [Kernel Patch] sched_autogroup

Message par bailchanis » jeu. 18 nov. 2010, 18:51

chipster a écrit :-j3 car tu avais 3 cores ??
Non, autant pour moi c'était 5 la base ... la reco classique étant : nombre de cores + 1 et pas -1 ... 4 cores = j5
My bad sur ce coup. mais ça fait un moment que j'ai plus compilé une gentoo.
(d'ailleurs j'aurais pu m'en douter sur un mono-cpu on va pas compiler avec 0 thread :mrgreen: ).
chipster a écrit :des perfs jusqu'à 15/17, ça veut dire quoi et tu l'as mesuré comment ?
Je l'ai dit : le temps mis à compiler les paquets (genlop -t) . OpenOffice, le kernel, vlc, firefox... sous gentoo on compile tout alors c'est pas très dur d'avoir des exemples de gros paquets où quelques % de différence se traduisent en minutes.
Bien entendu je nettoyais le cache de compilation à chaque fois pour comparer histoire de pas avoir d'effet biaisant de ce coté.

Après je n'ai pas de i7 et je ne sais pas à quel point on peut gagner de temps en poussant la charge sur ce genre de proco, mais avec 8 cores et une architecture un peu optimisée , pouvoir passer à 64 ne me parait pas d'emblée complètement hors de possibilité.
chipster a écrit : Les 64 threads créés, ils finissent où ? :D
j'aurai bien une réponse en trois lettres... :humour:
Plus sérieusement, ils finissent probablement au même endroit que les 15threads sur mon Q6600.

autant je ne saurais pas décrire les mécanismes dans le détails autant à l'usage tu auras du mal, malgré toute ta science de comment ça marche à l'intérieur, à me convaincre que la théorie l'emporte sur la pratique...
Dis moi que tu as compilé sur un i7 et que tu as observé que les gains en temps de compilation s'arrêtent à une valeur bien en dessous de 64... je te croirai. Mais comme tu as l'air de sous entendre que c'est évident je mets mon grain de sel pour dire que c'est p'tet pas si évident que ça. On peut surcharger les cores avec plein de threads et gagner du temps de compilation !

Après, que le gain ne justifie pas l'effort (sous entendu du patch) , parce que le gain est marginal ou parce qu'il ne va servir à presque personne ou que ceux à qui il peut servir savent se débrouiller autrement... peut être mais de là à dire que ça ne sert à strictement rien ... :roll:

D'ailleurs c'est exactement ce que je lis sur le blog de ck :
une telle optimisation (pour 64 threads de compilation) n'est utile que pour la compilation et pour ceux qui compilent beaucoup et elle peut être réalisée autrement que par le patch présenté... (avec un nice ou par schedtool ).


PS : je n'irai pas jusqu'à dire que je sais comment ça fonctionne , pour de vrai, mais je sais à quoi ça sert et je sais ce que c'est que la compilation parallèle :p

Avatar de l’utilisateur
chipster
Maître du Kyudo
Messages : 2063
Inscription : ven. 11 août 2006, 22:25
Localisation : Saint-Étienne (42)
Contact :

Re: [Kernel Patch] sched_autogroup

Message par chipster » jeu. 18 nov. 2010, 19:46

genlop un outil de test :lol:
Au fait, tu as écrit tout ça pour démontrer quoi puisque tu le dis toi même tu ne sais pas à quoi ça sert et tu n'amènes aucun test ? :mrgreen:

bailchanis
Daikyu
Messages : 71
Inscription : mar. 08 déc. 2009, 02:15

Re: [Kernel Patch] sched_autogroup

Message par bailchanis » jeu. 18 nov. 2010, 20:25

chipster a écrit :genlop un outil de test :lol:
Au fait, tu as écrit tout ça pour démontrer quoi puisque tu le dis toi même tu ne sais pas à quoi ça sert et tu n'amènes aucun test ? :mrgreen:
Puisque tu deviens désagréable, je peux le devenir aussi : apprend à lire.

J'ai dit que je sais à quoi sert la compilation parallèle . J'ai dit que je ne connais pas toutes les implications et je ne sais pas comment expliquer que dépasser de beaucoup le nombre de coeurs en threads peut améliorer le temps de compilation.

genlop -t donne le temps que la machine à mis pour compiler un paquet. En l'utilisant intelligemment (notamment en évitant les effets de caching, en répétant les expériences, en utilisant des gros paquets pour que les différences aient des chances d'être marquées et en calculant les marges d'erreur de l'échantillon.... ) on peut comparer les différents temps mis à compiler un même paquet avec des options différentes... mais c'est peut être trop compliqué pour toi à comprendre? Ou alors as-tu tellement mal lu que tu as cru que je parlais des perfs du système après la compilation et pas de la perf comme "temps mis à compiler un paquet"... ? Si c'est le cas, je ré-itère mon conseil sur l'effort de lecture.

Toi qui est si savant et tellement pointu sur ce paramètre de compilation, tu vas sans doute m'expliquer ce qui fait que compiler en utilisant 64 threads est strictement inutile sur un core i7 .... avec autre chose qu'un argument d'autorité, hein ...

Et pour répondre à la partie presque pertinente de ta question :
J'ai écris ma première réponse parce que tu semble te gausser d'un paramètre de compilation sans donner d'explication et que mon expérience (si maigre soit-elle) me laisse à penser que ce n'est peut-être pas si ridicule que cela. A la base, donc, je demande pourquoi tu dis ça, je suggère une réponse qui me parait possible et j'indique en quoi mon expérience me dit autre chose...
Tu réponds à ma question "pourquoi dis tu que ça ne sert strictement à rien?" par "moi je sais et pas toi alors la ramène pas".
C'est un peu dommage : je n'ai jamais remis en cause ta bonne foi, j'ai apporté un éclairage différent qui indique pourquoi je ne comprend pas ta remarque.

M'aurais-tu répondu que "oui mais gaver autant de thread si c'est pour ralentir l'execution ensuite avec une priorité affaiblie c'est pas vraiment utile" j'aurai mieux compris, mais visiblement tu préfères remettre en cause ce que j'ai observé.

Avatar de l’utilisateur
chipster
Maître du Kyudo
Messages : 2063
Inscription : ven. 11 août 2006, 22:25
Localisation : Saint-Étienne (42)
Contact :

Re: [Kernel Patch] sched_autogroup

Message par chipster » jeu. 18 nov. 2010, 21:16

Je ne suis pas désagréable mais toi si. Juste que tu me fais :lol:
Ne casse pas la tête à m'expliquer, avant de venir ici j'étais sous gentoo :)

Un time fait la même chose et ça ne change rien

Juste que venant de la part d'un dev kernel de voir ce genre de conneries avec -j64 je trouve ça pitoyable :evil:
Après c'est une histoire de gout :mrgreen:

Bon, on arrête le sujet car ça ne mène à rien. Dommage que ça parte en sucette comme ça

Avatar de l’utilisateur
chipster
Maître du Kyudo
Messages : 2063
Inscription : ven. 11 août 2006, 22:25
Localisation : Saint-Étienne (42)
Contact :

Re: [Kernel Patch] sched_autogroup

Message par chipster » jeu. 18 nov. 2010, 21:44

Benjarobin voulait rajouter quelque chose et je pense que c'est utile donc je rajoute ici :
Bon, je me joins à cette conversation, je suis en effet d'accord que 64 threads pour un seul pauvre processeur bien que multi-coeurs c'est un "peu" bizarre.
Je te laisse lire ceci http://en.wikipedia.org/wiki/Context_switch
Donc en effet, en théorie plus on a de thread par coeur, plus on est lent. Je ne parle même pas du cache L1, L2 du processeur qui souffre énormément avec tous ces contextes switch... Donc en effet je serais curieux de voir ce que cela donne 64 threads vs 10-12 threads sur mon i7 mais j'ai pas vraiment le temps pour cela ^^
Pour continuer et finir afin que ce thread soit complet, le fait d'en déclarer plus que le nombre de coeur dispo fait que les threads passent en queue ce qui sature en I/O le processeur donc perte importante de vitesse. Le seul avantage c'est que les threads étant créés, ils seront plus rapide à récupérer mais le fait de saturer le processeur en I/O sur la queue le rendra globalement plus lent ...

Verrouillé