lkml.org 
[lkml]   [2005]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
From
Date
On Fri, 2005-01-28 at 10:11 +0100, Ingo Molnar wrote:
> * Jack O'Quin <joq@io.com> wrote:
>
> > > thus after a couple of years we'd end up with lots of desktop apps
> > > running as SCHED_FIFO, and latency would go down the drain again.
> >
> > I wonder how Mac OS X and Windows deal with this priority escalation
> > problem? Is it real or only theoretical?
>
> no idea. Anyone with MacOSX/Windows application writing experience? :-|
>

Here's the description from Apple.
(from
http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/scheduler/chapter_8_section_4.html):

However, according Stéphane Letz who ported JACK to OSX, this does NOT
describe the reality of the current implementation - it's not a real
deadline scheduler. "period" and "constraint" are ignored, RT tasks are
scheduled round robin, and the scheduler just uses "computation" as the
timeslice. If an RT task repeatedly uses its entire timeslice without
blocking, the scheduler can demote the task to SCHED_NORMAL.

Audio apps do not normally set these parameters directly, the CoreAudio
backend handles it.

(quoting Stéphane Letz)

> For example in CoreAudio, the computation value is directly related
> to the audio buffer size in the following way:
>
> buffer size computation
>
> 64 frames 500 us
> 128 300 us
> >= 256 100 us
>
> The idea is that threads with smaller buffer size will get a larger
> computation slice so that there is a chance they can complete their
> jobs. Threads with larger buffer size are more interruptible. The
> CoreMidi thread (to handle incoming Midi events) also has a
> computation value of 500 us.

> Other RT threads like Firewire and various system threads computation
> value are also carefully chosen.

(This was from a private mail thread, that lead to Con's SCHED_ISO patches,
if all the participants agree I will post a link to the full thread because
it answers many questions that are sure to come up on LKML)

So this system *requires* an app to tell the kernel in advance what its
RT constraints are, then revokes isochronous scheduling privileges if
the task lied. This would require a new API. Furthermore I suspect
that these "System" threads aren't subject to having their RT privileges
revoked, and that the GUI gets special treatment, etc.

The upshot is while the OSX system works in that environment, it's
largely due to Apple controlling the kernel and a lot of userspace. OSX
is useful as a model of what a good API for soft realtime support in a
desktop OS would look like. But we are a general purpose OS so we
certainly need a more general solution.

Lee

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

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.409 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site