RE: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

["David Schwartz" <davids@webmaster.com>]

> * Mike Galbraith <efault@gmx.de> wrote:
>
> > [...] The situation as we speak is that you can run cpu intensive
> > tasks while watching eye-candy.  With RSDL, you can't, you feel the
> > non-interactive load instantly. [...]
>
> i have to agree with Mike that this is a material regression that cannot
> be talked around.

I don't know what else you can do when the argument is that behavior that is
wrong is what you actually want. The regression is not that the scheduler
doesn't do what it was asked to do or even that it isn't more faithful to
what it was told to do than the scheduler it replaces. The regression is
that the scheduler didn't do what Mike wanted it to do, even though he
didn't ask it to do that.

I would argue this is progression, not regression. The new scheduler is
fairer than the old one and fairness is good even though it sometimes hurts
some tasks.

> Con, we want RSDL to /improve/ interactivity.

Not when the interactivity was the result of unfairness.

> Having new scheduler
> interactivity logic that behaves /worse/ in the presence of CPU hogs,
> which CPU hogs are even reniced to +5, than the current interactivity
> code, is i think a non-starter. Could you try to fix this, please?

If you did this, it would mean that all the space between the signficant
level of unfairness you want in this case and pure fairness would have to
fit in five nice levels. That just seems like poor granularity.

> Good
> interactivity in the presence of CPU hogs (be them default nice level or
> nice +5) is _the_ most important scheduler interactivity metric.
> Anything else is really secondary.

Good interactivity for tasks that aren't themselves CPU hogs. A task should
get low latency if and only if it's yielding the CPU voluntarily most of the
time. If it's not, it can only get better interactivity at the cost of
fairness, and you have to *ask* for that. (Common sense says you can't give
a task *more* CPU because it yields the CPU a lot. And how else do you
determine interactivity other than nice level?)

This scheduler will not give you greater interactivity at the cost of
fairness unless you really ask for it. I think that's a good thing, though I
do agree it might take some getting used to.

I'm not saying it is impossible to make RSDL better at handling this
particular job. I'm saying the "regression" may be the scheduler doing what
it was asked to do more faithfully than the current scheduler and the right
fix (at least in the longer term) is to ask for what you really want.

DS