There has been a little cross talk lately about the "HP" schedulers that
may be sowing some confusion.
1) Pluggable policies provides a minimally intrusive way to develop and
test new scheduler policies such as Processor Sets, or the Fair Share
Scheduler. It provides a good way to test a theory without rebooting.
(Linus said that this approach was useful for experiments but was too
dangerous to allow in the main line kernel. sigh. We're still working on a
way to get *some* flexibility via goodness, etc.)
2) The Multi-queue approach I put on our web site is not pluggable, because
the prototype didn't generate enough interest or performance improvement.
It was an academic exercise showing what I considered the minimum change
necessary. It took about two days to code and measure the revised scaling.
Consider it the opening volley of a group discussion, not a finished product.
3) the cpu stealing rules try to mimic those for a earlier kernel for an i386
architecture. Due to the ~20 penalty, stealing was not mathematically
possible between cpus until everything with preference for that CPU has
reached 0 count. When one queue is empty, I try to emulate the single
queue behavior and pick the best job from all queues. This was for
simplicity and compatibility, not fairness or speed.
What they say is true, there is no such thing as bad publicity. I've had more
MQ downloads this week than I did when they were new.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
