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.
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
[^] # Re: C'est l'ordonnanceur...
Posté par Stephane Marchesin . En réponse au journal Multitache bizarre. É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 ?