Avec le kernel 2.6 de mdk non préemptif, lorsque je compile un programme, le système n'est pas trop ralenti(chose exeptionelle avec un PII 300mhz 256Mo de RAM GeFORCE 4MX440). Mais lorsque je fait un solarwolf avec mozilla & gaim de lancé (sous KDE) parfois, le système se fige un dixième de seconde, temps suffisant pour me retourver éclaté devant un vaisseau ennemi.
Que faire?
Note: avec chromium, no pbs
Journal Multitache bizarre
19
mai
2004
# Ah solarwolf !
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Mais je suis, dans une autre partie, au niveau 30 après 73 vies. Et c'est trop duuuuur ! Vous avez des astuces ?
Sinon, pour ton problème, cela ne vient-il pas du graphisme ? Que te donne un glxgears ?
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Ah solarwolf !
Posté par Yann012 . Évalué à 1.
[^] # Re: Ah solarwolf !
Posté par Yann012 . Évalué à 1.
Par contre, C chiant que le fichier de conf soit en binaire car mon nom est No Name...
# C'est l'ordonnanceur...
Posté par Stephane Marchesin (site web personnel) . Évalué à 4.
Du coup, solarwolf est pénalisé et lagge dès qu'il y a autre chose qui veut tourner. Par contre, chromium qui ne tourne pas à 100% de cpu n'a pas ce problème.
Que faire ? Changer d'ordonnanceur :
- repasser au 2.4 (eh oui pour les jeux c'est pas plus mal)
- patcher ton noyau 2.6. Le patch isochronous de Con Kolivas est ce que tu cherches, mais il nécessite de lancer les programmes avec des utilitaires user space
- essayer d'autres ordonnanceurs "experimentaux". Pareil il faudra patcher ton noyau. Je n'ai pas de patch en particulier qui me vient à l'esprit, là maintenant. Peut-etre que le noyau multimedia de mandrake intègre de tels patchs.
[^] # Re: C'est l'ordonnanceur...
Posté par ckyl . Évalué à 5.
Heu tu es au courant *tout* ordonnanceur pénalise certaines taches et en favorisent d'autre ? Ca tombe bien puisque c'est son job. L'ordo du 2.6 n'apporte rien de nouveau de ce côté grosso modo on regarde qui bouffe du CPU et on le puni pour favorisé les autres taches (je vais pas expliquer le pourquoi du comment ici).
Ce qu'apporte le 2.6 c'est surtout en reduction de la complexité des algos de gestion. Une passe des queues de priorité multiniveau en O(n) a des algos 0(1) car basé sur des evenements. Encore groso modo tu ne mets a jour que la structure de la tache qui vient de se terminer et tu la balances en queue d'une FIFO.
- essayer d'autres ordonnanceurs "experimentaux"
Le seul ordonnanceurs expérimentale qui existe et qui fonctionne a peu près a ma connaissance est staircase de ck. Pour l'avoir fait tourné pendant un mois il est pas au point (jolie famine par moment, et freeze de machine pour 1..10 secondes dans des cas pathologiques reproductible).
La solution ? Apprendre a se servir des primitives POSIX concernant l'ordonnancement ! Bin oui le bon vieux nice
nice A
nice +20 B
B ne passera *jamais* devant A par exemple.
les prioros vont de -20 à +19 à toi de jouer avec cela. Un algo d'ordonancement c'est stupide et il ne peut pas vraiment faire la différence entre un process a la con qui bouffe 100% de CPU et un jeux qui faut qu'il tourne qui bouffe 100% de CPU. On laisse donc l'utilisateur biaiser les choix de l'algo.
Autrement tu peux carrement tapper du cote des prio temps reel mais si ton jeux par en vrille tu es bon pour le reboot :-)
J'avais quelques idée bassée sur les attributs etendus des FS pour faire cela de manière plus souple et peut être qu'un jour je testerais mes idéees :-)
[^] # Re: C'est l'ordonnanceur...
Posté par Stephane Marchesin (site web personnel) . Évalué à 4.
Euh, tu es sur d'avoir suivi le développement du 2.6 ? On t'a dit que le scheduler a changé quasiment du tout au tout entre 2.4 et 2.6 ? Si tu as suivi ces discussions, tu te rapelleras la discussion sur XFree qui laggait plus avec le 2.5.X qu'avec les 2.4, et le fait que c'était lié aux modifs du scheduler, et le fait que le pauvre linus ne pouvait pas voir de différence sur son quadri proc :
http://kerneltrap.org/node/view/603/2629(...)
Le seul ordonnanceurs expérimentale qui existe et qui fonctionne a peu près a ma connaissance est staircase de ck. Pour l'avoir fait tourné pendant un mois il est pas au point (jolie famine par moment, et freeze de machine pour 1..10 secondes dans des cas pathologiques reproductible).
Bah, en meme temps, le staircase est loin d'etre fini. Et des schedulers experimentaux, il y en a des plus connus que celui-là. Essaye déjà les noyaux -mm.
La solution ? Apprendre a se servir des primitives POSIX concernant l'ordonnancement ! Bin oui le bon vieux nice
nice A
nice +20 B
B ne passera *jamais* devant A par exemple.
Ca dépend ce que tu apelles "passer devant A". Si A et B sont tous les 2 des cpu hogs, chacun aura une part du CPU. Certes, B sera fortement défavorisé mais tournera quand meme un peu. Le fait meme que B obtienne une part du cpu veut dire que A (qui tourne pourtant à 100% de cpu tout le temps) a été préempté pour laisser passer B devant A.
Le nice n'influe pas sur ce problème, si tu avais essayé cette solution tu le saurais. D'ailleurs ça a été discuté avant hier à la réunion irc hebdomadaire du dri :
http://dri.sourceforge.net/IRC-logs/20040517.txt(...)
Où une personne a exactement ce problème, meme à un nice -19.
[^] # Re: C'est l'ordonnanceur...
Posté par ckyl . Évalué à 3.
J'ai juste écrit un commentaire de code de l'ordo O(1) en francais y'a un peu plus d'un an... :-)
Mais je t'avoue que je n'ai plus tout les details en tête du O(1) j'ai fait quelques trucs depuis
> Essaye déjà les noyaux -mm.
Je suis pas du tout les noyaux -mm en ce moment. Hormis sched domains qui n'a rien a voir avec la tambouille tu peux me dire ce qu'il y d'interessant dans la tambouille ? Je viens de matter le patch-series du 2.6.6-mm4 et j'ai rien pu trouver avec un nom qui semble interessant.
> Ca dépend ce que tu apelles "passer devant A".
Dans le cas du 2.6 tu as en effet raison je viens de re-matter rapidos les sources.
Avec des nices a 0 et 19 et des taches bouffeuses de CPU un peu facilement prédire que les deux taches ne seront pas classées interactives. Donc ne seront jamais remise dans la queue courante. Vu qu'au minimum MIN_TIMESLICE est attribué a chaque tache lors de sa mise dans la seconde queue en effet les deux tâches s'executerons. Tiens c'est bizarre je suis paresseux aujourd'hui je te laisse faire le calcul grosso modo des timeslice allouées aux deux process :-)
Autrement en relisant le code je n'ai pas pu trouver de tracer de SCHED_BATCH qui me semble pourtant bien avoir existé. ie une classe d'ordonnancement ou les taches recoivent des timeslice de l'ordre de 10 * MAX_TIMESLICE mais ne peuvent préempter aucune autre tache et un simple round robin est fait entre les tâches. J'ai revé ou 1/ je devrais me raffraichir la mémoire 2/ ca a été viré depuis les premiers patchs ? Je me souviens même du .c donné par molnar pour passer une tache en SCHED_BATCH.
Pour ton log :
Grievre: another part of the problem is that the 2.6 scheduler punishes CPU hogs;
C'est une affirmation correcte mais pas complete. Tout les ordos generalistes que je connais (regarde decay par exemple, 2.4 en est une adaptation) punissent toujours les taches consomatrices de CPU donc a priori non interactives. Ce qui serait interessant c'est de voir exactement la différent au niveau de la punission et de la répartition de chaque ordonnancement selon les ordonanceurs.
La solution simple est toujours de passer la tache en temps réel (SCHED_FIFO/SCHED_RR) et la tu es sur qu'elle ne se fera pas massacrer par les autres autre mais toujours au risque de perdre la machine si le jeux se vautre.
Bon si j'ai du temps a perdre je ferais des stats tiens
[^] # Re: C'est l'ordonnanceur...
Posté par Stephane Marchesin (site web personnel) . Évalué à 2.
Je skip, tu y as répondu.
Dans le cas du 2.6 tu as en effet raison je viens de re-matter rapidos les sources.
Avec des nices a 0 et 19 et des taches bouffeuses de CPU un peu facilement prédire que les deux taches ne seront pas classées interactives. Donc ne seront jamais remise dans la queue courante. Vu qu'au minimum MIN_TIMESLICE est attribué a chaque tache lors de sa mise dans la seconde queue en effet les deux tâches s'executerons. Tiens c'est bizarre je suis paresseux aujourd'hui je te laisse faire le calcul grosso modo des timeslice allouées aux deux process :-)
A la louche, deux cpu hogs dont l'un est à nice 20 et l'autre à 0 se partagent le cpu à un ratio de 1 vs 20 (les slices max et min). Le problème, c'est que celui qui est à 0 tourne plus et donc est pénalisé. Donc c'est un peu plus que 1/21 pour celui qui est à nice 20. 1 pour 10 ?
Autrement en relisant le code je n'ai pas pu trouver de tracer de SCHED_BATCH qui me semble pourtant bien avoir existé. ie une classe d'ordonnancement ou les taches recoivent des timeslice de l'ordre de 10 * MAX_TIMESLICE mais ne peuvent préempter aucune autre tache et un simple round robin est fait entre les tâches. J'ai revé ou 1/ je devrais me raffraichir la mémoire 2/ ca a été viré depuis les premiers patchs ? Je me souviens même du .c donné par molnar pour passer une tache en SCHED_BATCH.
Skip, tu as répondu.
Sinon, SCHED_BATCH ça se trouve en général dans les systèmes de calcul hautes performances ou l'ordonnancement est statique (fait par un système qui fait l'association 1 process <-> 1 cpu). Les memes systèmes tournent d'ailleurs avec HZ=20, en général.
Pour ton log :
Grievre: another part of the problem is that the 2.6 scheduler punishes CPU hogs;
C'est une affirmation correcte mais pas complete. Tout les ordos generalistes que je connais (regarde decay par exemple, 2.4 en est une adaptation) punissent toujours les taches consomatrices de CPU donc a priori non interactives. Ce qui serait interessant c'est de voir exactement la différent au niveau de la punission et de la répartition de chaque ordonnancement selon les ordonanceurs.
C'est vrai que ce n'est pas très précis. Mais l'idée est là : sur un 2.6, les taches qui mangent 100% de cpu peuvent se faire méchamment préempter à cause du système de sleep_avg spécifique aux 2.6 qui veut que si tu ne dors pas assez, tu es moins prioritaire.
La solution simple est toujours de passer la tache en temps réel (SCHED_FIFO/SCHED_RR) et la tu es sur qu'elle ne se fera pas massacrer par les autres autre mais toujours au risque de perdre la machine si le jeux se vautre.
C'est encore pire : tourner une appli non temps réel avec un scheduler temps réel relève de la folie. Si tu lis le log, en fait le gars a planté sa machine parce que son jeu prenait 100% de cpu et Xfree n'avait plus rien, ce qui l'a forcé à s-u-b (d'ailleurs après, il était faché, il parlait en gras, mais ca ne se voit pas dans le log :)
Bon si j'ai du temps a perdre je ferais des stats tiens
Euh.. des stats de quoi ?
[^] # Re: C'est l'ordonnanceur...
Posté par ckyl . Évalué à 2.
> Je skip, tu y as répondu
heu non pour deux raisons
1/ dans le patchset d'-mm je ne vois pas les patchs de ck
2/ même s'ils y etaient SCHED_BATCH & SCHED_ISO ne sont clairement pas des ordonnanceurs. Juste des bidouille (ie. des patchs de 15 lignes) pour adapter le comportement bref rien de .
Staircase c'est pas un hack "a la va vite" mais un changement en profondeur de sched.c (d'ailleur il est domage que sous linux on ne puisse pas avoir proprement plusieurs ordonanceurs à la FreeBSD par exemple, mais je peux encore ne pas avoir suivit les tout dernier developements). Il remet en cause pas mal de principes apportés par le patch de molnar.
>Sinon, SCHED_BATCH ça se trouve en général dans les systèmes de calcul hautes performances ou l'ordonnancement est statique
heu ca peut quand même être très pratique sur des WS ou des serveurs.
> C'est encore pire
Hihi tu as clairement raison je me demande comment j'ai dit une connerie comme ca :-/
[^] # Re: C'est l'ordonnanceur...
Posté par Stephane Marchesin (site web personnel) . Évalué à 3.
http://www.kerneltrap.org/~npiggin/v19a/broken-out/sched-policy.pat(...)
Staircase c'est pas un hack "a la va vite" mais un changement en profondeur de sched.c (d'ailleur il est domage que sous linux on ne puisse pas avoir proprement plusieurs ordonanceurs à la FreeBSD par exemple, mais je peux encore ne pas avoir suivit les tout dernier developements). Il remet en cause pas mal de principes apportés par le patch de molnar.
Non non loin de moi l'idée que c'est un hack, j'ai juste dit que c'était pas fini :)
[^] # Re: C'est l'ordonnanceur...
Posté par ckyl . Évalué à 2.
J'ai bien compris le principe du SCHED_ISO par contre je ne suis pas sur de voir toutes les implications dans le monde réel du deadline--. Faudra que j'y reflechisse un peu ! Mais il semble que ce soit la réponse élégante à la question. Faut juste que j'arrive a jauger jusqu'à quel point la réponse est pertinante par rapport à la question.
[^] # Re: C'est l'ordonnanceur...
Posté par Stephane Marchesin (site web personnel) . Évalué à 2.
Isochronous scheduling?
Isochronous scheduling (or guaranteed time scheduling) is an alternative to real time scheduling that can be used without root privileges. SCHED_ISO tasks do not "expire" in the scheduler, guaranteeing relatively low latency even if they are fully cpu bound. This is good for cpu intensive tasks that would not normally be seen as interactive. It is useful for gaming, video capture, video playback at limits of performance, audio sampling etc. You can also set a task as SCHED_ISO using the schedtools utility. eg: ' schedtool -I -e "streamer ..." ' will start the video capture application streamer as ISO. Alternatively if you start an application that tries to get real time scheduling (like xmms) but you do not have root privileges, it will automatically be made SCHED_ISO.
C'est juste pour dire que c'est censé faire exactement ce qu'on en attend.
J'ai bien compris le principe du SCHED_ISO par contre je ne suis pas sur de voir toutes les implications dans le monde réel du deadline--. Faudra que j'y reflechisse un peu ! Mais il semble que ce soit la réponse élégante à la question. Faut juste que j'arrive a jauger jusqu'à quel point la réponse est pertinante par rapport à la question.
deadline-- ? Je vois pas de quoi tu parles.
Sinon, à en juger par la partie qu j'ai mise en gras, ça répond à la question.
[^] # Re: C'est l'ordonnanceur...
Posté par ckyl . Évalué à 2.
si tu regardes le patch pour le SCHED_ISO tu verras de quoi je parles :-)
> Sinon, à en juger par la partie qu j'ai mise en gras, ça répond à la question.
Non ca c'est le résumé de ck pour que ca soit compréhensible ce a quoi il faut que je refléchisse c'est sur ce que modifie effectivement le code (très très peu de choses) et toutes les implications que cela entraine. Et pourquoi cette modification fonctionne et répond à la question. Enfin bref
[^] # Re: C'est l'ordonnanceur...
Posté par Stephane Marchesin (site web personnel) . Évalué à 3.
Hehe... je me suis posé des questions, parce que j'ai greppé et j'ai rien trouvé. Mais en fait, dans le 2.6.6-mm4 ça n'y est plus. Et effectivement, en regardant le lien que tu pointes, le 2.6.4-mm, ça y est.
[^] # Re: C'est l'ordonnanceur...
Posté par Stephane Marchesin (site web personnel) . Évalué à 3.
D'oh autant pour moi tu pointes le 2.6.4-ck. Je devrais regarder la tronche des liens avant de cliquer, j'ai cru à un 2.6.4-mm
Bon pour etre clair on parle de deux choses :
- les -mm qui n'ont pas SCHED_ISO mais un bel ordonnanceur tout neuf
- les -ck qui apportent SCHED_ISO et je crois pas grand chose (rien ?) pour l'ordonnanceur
[^] # Re: C'est l'ordonnanceur...
Posté par ckyl . Évalué à 2.
- les -ck qui apportent SCHED_ISO et je crois pas grand chose (rien ?) pour l'ordonnanceur
Rien hormis staircase quand il sera fini. En plus ck a l'air d'etre occupé à autre chose et les patch contre le 2.6.4 commencent a rejetter de partout sur un 2.6.6 tout frais.
Enfin tu as aussi sched_domain mais on ne joue pas dans le même domaine (c'est pour la migration de tache entre les CPUs). http://lwn.net/Articles/80601/(...) pour un tour de vue rapide.
# Nice ruleeez
Posté par Yann012 . É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.