Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches

[Daniel Phillips <phillips@arcor.de>]

On Wednesday 06 August 2003 22:28, Rob Landley wrote:
> So, how does SCHED_SOFTRR fail?  Theoretically there is a minimum timeslice
> you can hand out, yes?  And an upper bound on scheduling latency.  So
> logically, there is some maximum number "N" of SCHED_SOFTRR tasks running
> at once where you wind up round-robining with minimal timeslices and the
> system is saturated.  At N+1, you fall over.  (And in reality, there are
> interrupts and kernel threads and other things going on that get kind of
> cramped somewhere below N.)

The upper bound for softrr realtime scheduling isn't based on number of tasks, 
it's a global slice of cpu time: so long as the sum of running times of all 
softrr tasks in the system lies below limit, softrr tasks will be scheduled 
as SCHED_RR, otherwise they will be SCHED_NORMAL.

> In theory, the real benefit of SCHED_SOFTRR is that an attempt to switch to
> it can fail with -EMYBRAINISMELTING up front, so you know when it won't
> work at the start, rather than having it glitch halfway through the run. 

Not as implemented.  Anyway, from the user's point of view, that would be an 
unpleasant way for a sound player to fail.  What we want is something more 
like a little red light that comes on (in the form of error statistics, say) 
any time a softrr process gets demoted.  Granted, there may be situations 
where what you want is the right behavior, but it's (as you say) a separate 
issue of resource allocation.

Regards,

Daniel