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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 07 2003 - 22:00:40 EST