On Sunday 27 July 2003 11:46, Daniel Phillips wrote:
> The definition of a realtime scheduler is that the worst case latency is
> bounded. The current crop of interactive tweaks do not do that. So we
> need a scheduler with a bounded worst case. Davide Libenzi's recent patch
> that implements a new SCHED_SOFTRR scheduler policy, usable by non-root
> users, provides such a bound. Please don't lose sight of the fact that
> this is the correct solution to the problem, and that interactive tweaking,
> while it may produce good results for some or even most users in some or
> even most situations, will never magically transform Linux into an
> operating system that an audiophile could love.
Thinking out loud for a bit, please tell me if I'm wrong about SCHED_SOFTRR...
Whatever the policy is, there's only so many ticks to go around and there is
an overload for which it will fail. No resource allocation scheme can
prevent starvation if there simply isn't enough of the resource to go around.
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.)
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. At which
point half the fun becomes policy decisions about how to allocate the finite
number of SCHED_SOFTRR slots between however many users are trying to use the
system, which gets into Alan Cox's accounting work...
Sorry if this is old hat; I'm still a week and change behind on the list, but
catching up... :)
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:36 EST