Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches

[Rob Landley <rob@landley.net>]

On Thursday 07 August 2003 11:42, Daniel Phillips wrote:
> 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.

I thought one of the advantages here was that a userspace program could give 
hints about whether the scheduler should optimize it for latency or for 
throughput, without having to be root.

XFree86 and Konqueror Xterm and Kmail could all say "latency in me is end-user 
visible, so I care more about latency than throughput".  And stuff like the 
nightly cron job that exists just to screw up my desktop because I AM awake 
at 4 am a noticeable percentage of the time...  Anyway, it cares about 
throughput and not at all about latency.  Same with just about any invocation 
of gcc, so they'd never set the flags.

If Bash really wanted to get fancy, it could set the flag depending on whether 
the process on the other end of its input PTY had the flag or not, but let's 
worry about that later... :)

> > 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.

Uh-huh.

So with SCHED_SOFTRR, if the system gets heavily loaded enough later on then 
the SOFTRR tasks can get demoted and start skipping.  So we're back to having 
a system where cron had better not start up while you're mixing sound because 
it might put you over the edge.

I fail to see how this is an improvement on Con's "carpet bomb the problem 
with heuristics out the wazoo" approach?  (I like heuristcs.  They're like 
Duct Tape.  I like Duct Tape.)

> Regards,
>
> Daniel

Rob