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.
Not when the interactivity was the result of unfairness.
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 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
-
