[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
    On Fri, 2005-01-28 at 10:11 +0100, Ingo Molnar wrote:
    > * Jack O'Quin <> 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.

    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [W:0.023 / U:11.292 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site