>>> Et c'est pas comme si on pouvais pas avoir plus d'un ordonnanceur dans les sources du noyau.
Le problème avec cette solution de mettre plusieurs schedulers dans le noyau c'est qu'il y aura moins de travail de fiabilisation sur chacun.
Il vaut mieux avoir un seul scheduler adaptable aux différents types de machines....comme l'est CFS actuellement !
Un mec posait la question à Ingo : "So what happened to pluggable schedulers?"
Sa réponse (un tantinet ironique) :
"In fact, wouldn't it be even cooler technically to have a scheduler that you could tune either for low-latency desktop workloads or for server-oriented throughput workloads? And this could all be done runtime, without rebooting the kernel.
Some easy runtime tunable parameter in /proc/sys/kernel/ that sets the expected preemption deadline of tasks. So on a server you could tune it to 100 msecs, on a desktop could tune it to 5 msecs - all with the same scheduler.
No reboots needed, only a single scheduler needs to be maintained, only a single scheduler needs bugfixes - and improvements to both workloads will flow into the same scheduler codebase so server improvements will indirectly improve the desktop scheduler and vice versa.
[^] # Re: Le quad core devient le bas de gamme!
Posté par patrick_g (site web personnel) . En réponse au journal BFS : La revanche. Évalué à 5.
Le problème avec cette solution de mettre plusieurs schedulers dans le noyau c'est qu'il y aura moins de travail de fiabilisation sur chacun.
Il vaut mieux avoir un seul scheduler adaptable aux différents types de machines....comme l'est CFS actuellement !
Un mec posait la question à Ingo : "So what happened to pluggable schedulers?"
Sa réponse (un tantinet ironique) :
"In fact, wouldn't it be even cooler technically to have a scheduler that you could tune either for low-latency desktop workloads or for server-oriented throughput workloads? And this could all be done runtime, without rebooting the kernel.
Some easy runtime tunable parameter in /proc/sys/kernel/ that sets the expected preemption deadline of tasks. So on a server you could tune it to 100 msecs, on a desktop could tune it to 5 msecs - all with the same scheduler.
No reboots needed, only a single scheduler needs to be maintained, only a single scheduler needs bugfixes - and improvements to both workloads will flow into the same scheduler codebase so server improvements will indirectly improve the desktop scheduler and vice versa.
Sounds like a nice idea, doesn't it? "