[lkml]   [2006]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: was Re: quell interactive feeding frenzy
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

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.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-04-16 21:10    [W:0.056 / U:19.632 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site