Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5

[Peter Williams <pwil3058@bigpond.net.au>]

Al Boldi wrote:
> Peter Williams wrote:
>> Al Boldi wrote:
>>> Peter Williams wrote:
>>>> Al Boldi wrote:
>>>>>>>> Control parameters for the scheduler can be read/set via files in:
>>>>>>>>
>>>>>>>> /sys/cpusched/<scheduler>/
>>>>> The default values for spa make it really easy to lock up the system.
>>>> Which one of the SPA schedulers and under what conditions?  I've been
>>>> mucking around with these and may have broken something.  If so I'd
>>>> like to fix it.
>>> spa_no_frills, with a malloc-hog less than timeslice.  Setting
>>> promotion_floor to max unlocks the console.
>> OK, you could also try increasing the promotion interval.
> 
> Seems that this will only delay the lock in spa_svr but not inhibit it.

OK. But turning the promotion mechanism off completely (which is what 
setting the floor to the maximum) runs the risk of a runaway high 
priority task locking the whole system up.  IMHO the only SPA scheduler 
where it's safe for the promotion floor to be greater than MAX_RT_PRIO 
is spa_ebs.  So a better solution is highly desirable.

I'd like to fix this problem but don't fully understand what it is. 
What do you mean by a malloc-hog?  Would it possible for you to give me 
an example of how to reproduce the problem?

> 
>> It should be noted that spa_no_frills isn't really expected to behave
>> very well as it's a pure round robin scheduler.
> 
> It's a bare bone scheduler that allows to prioritize procs to the admins 
> desire, instead of leaving the priority management to the scheduler, which 
> may be undesirable for some but not all.

OK.  But it's important to realize that "nice" does not (in general) 
control the "amount of CPU" that tasks get with this scheduler.  It 
merely controls the order in which runnable tasks run i.e. it's a 
"priority based" interpretation of "nice" not an "entitlement based" 
interpretation.  The difference is important.

If you want a "bare bones" scheduler with an "entitlement based" 
interpretation of "nice" use spa_ebs with the maximum bonuses set to 
zero.  In that state spa_ebs is safe for promotion to be completely 
disabled unless you also want to use cpu caps (in which case you'd need 
to set the floor to about 137 to make sure that capped tasks don't get 
completely starved).

> 
>> It's intended purpose is as a basis for more sophisticated schedulers.
> 
> And that's why the same problem exists in the child scheds, i.e. spa_ws, 
> spa_svr, zaphod, but not spa_ebs.

OK.

> 
>> I've been thinking
>> about removing it as a bootable scheduler and only making its children
>> available but I find it useful to compare benchmark and other test
>> results from it with that from the other schedulers to get an idea of
>> the extra costs involved.

Thanks,
Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce