> Euh, tu es sur d'avoir suivi le développement du 2.6 ?
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 ckyl . En réponse au journal Multitache bizarre. É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