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).
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 Stephane Marchesin . En réponse au journal Multitache bizarre. É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.