- repasser au 2.4 (eh oui pour les jeux c'est pas plus mal)
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 ckyl . En réponse au journal Multitache bizarre. É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 :-)