Re: was Re: quell interactive feeding frenzy

[Al Boldi <a1426z@gawab.com>]

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/