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

[Jeremy Fitzhardinge <jeremy@goop.org>]

David Schwartz wrote:
>> There's a distinction between giving it more cpu and giving it higher
>> priority: the important part about having high priority is getting low
>> latency access to the cpu when its needed.
>>     
>
> I agree. Tasks that voluntarily relinquish their timeslices should get lower
> latency compared to other processes at the same static priority.
>
>   
>> This really seems like the wrong approach to me.  The implication here
>> and in other mails is that fairness is an inherently good thing which
>> should obviously take preference over any other property.
>>     
>
> Yes, that is the implication. The alternative to fairness is arbitrary
> unfairness. "Rational unfairness" is a form of fairness.
>
>   
>> The old unix-style dynamic priority scheme was designed to give
>> interactive processes high priorities, by using the observation that
>> "interactive" means "spends a lot of time blocked waiting for input".
>> That model of interactive is way too simple now, and the attempts to try
>> an find an equivalent heuristic have been flawed and lead to - in some
>> cases - wildly bad behaviours.  I'm guessing the emphasis on "fairness"
>> is in reaction to this, which is fair enough.
>>     
>
> I don't think it makes sense for the scheduler to look for some hint that
> the user would prefer a task to get more CPU and try to give it more. That's
> what 'nice' is for.
>
>   
>> But saying that the user needs to explicitly hold the schedulers hand
>> and nice everything to tell it how to schedule seems to be an abdication
>> of duty, an admission of failure.  We can't expect users to finesse all
>> their processes with nice, and it would be a bad user interface to ask
>> them to do so.
>>     
>
> Then you will always get cases where the scheduler does not do what the user
> wants because the scheduler does not *know* what the user wants. You always
> have to tell a computer what you want it to do, and the best it can do is
> faithfully follow your request.
>   

Hm, well.  The general preference has been for the kernel to do a
good-enough job on getting the common cases right without tuning, and
then only add knobs for the really tricky cases it can't do well.  But
the impression I'm getting here is that you often get sucky behaviours
without tuning.

> I think it's completely irrational to ask for a scheduler that automatically
> gives more CPU time to CPU hogs.
>   

Well, it doesn't have to.  It could give good low latency with short
timeslices to things which appear to be interactive.  If the interactive
program doesn't make good use of its low latency, then it will suck. 
But that's largely independent of how much overall CPU you give it.

> I agree. I'm not claiming to have the perfect solution. Let's not let the
> perfect be the enemy of the good though.
>   

For all its faults, the current scheduler mostly does a good job without
much tuning - I normally only use "nice" to run cpu-bound things without
jacking the cpu speed up.  Certainly in my normal interactive use of
compiz vs make -j4 on a dual-core generally gets pretty pretty good
results.  I plan on testing the new scheduler soon though.

    J