Re: was Re: quell interactive feeding frenzy

[Con Kolivas]

On Monday 17 April 2006 05:03, Al Boldi wrote:
> It's not bad, but it seems to allow cpu-hogs to steal left-over timeslices,
> which increases unfairness as the proc load increases.

Spot on.

> 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.

Not interested in hacking on something like that onto it. It was more of an 
experiment in the simplest possible starvation free design that still 
supported nice levels.

> 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.

While this may be the key, it is not the reason we aren't getting maximum 
roundness in our designs in linux. Our major enemy is cpu accounting of work 
done in kernel context on behalf of everyone else. Putting architecture 
dependant hooks into the assembly code to account for entry and exit would be 
the accurate way of doing this.

-- 
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/