Messages in this thread | | | From | Al Boldi <> | Subject | Re: was Re: quell interactive feeding frenzy | Date | Sun, 16 Apr 2006 22:03:31 +0300 |
| |
Con Kolivas wrote: > Al Since you have an unhealthy interest in cpu schedulers you may also > want to look at my ultimate fairness with mild interactivity builtin cpu > scheduler I hacked on briefly. I was bored for a couple of days and came > up with the design and hacked it together. I never got around to finishing > it to live up fully to its design intent but it's working embarassingly > well at the moment. It makes no effort to optimise for interactivity in > anyw way. Maybe if I ever find some spare time I'll give it more polish > and port it to plugsched. Ignore the lovely name I give it; the patch is > for 2.6.16. It's a dual priority array rr scheduler that iterates over all > priorities. This is as opposed to staircase which is a single priority > array scheduler where the tasks themselves iterate over all priorities.
It's not bad, but it seems to allow cpu-hogs to steal left-over timeslices, which increases unfairness as the proc load increases. Conditionalizing prio-boosting based on hogginess maybe one way to compensate for this. This would involve resisting any prio-change unless hogged, which should be scaled by hogginess, something like SleepAVG but much simpler and less fluctuating.
Really, the key to a successful scheduler would be to build it step by step by way of abstraction, modularization, and extension. Starting w/ a noop/RR-scheduler, each step would need to be analyzed for stability and efficiency, before moving to the next step, thus exposing problems as you move from step to step.
Thanks!
-- Al
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |