[lkml]   [2003]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] SCHED_SOFTRR linux scheduler policy ...
    On Sat, 12 Jul 2003, Miguel Freitas wrote:

    > I guess you are talking about mostly audio applications here. For video
    > playback these timings are even tighter and there is very little the
    > application itself can do to improve it (it's not a matter of increasing
    > the buffer size).

    Yes, it was audio I was talking about ...

    > > I have to say that on my machine (P4 2.4GHz),
    > > audio hardly skip during the typical load that my desktop sees, that in
    > > turn is not so high. Like you can see in the couple of graphs that I
    > > quickly dropped inside the SOFTRR page, typical latencies of 150ms are
    > > very easy to obtain.
    > 150ms latency would kill any video application.
    > There is no equivalent of sound card's or kernel audio buffers for
    > frames, the application just _have_ to be scheduled in time to display
    > the frame (basicaly tell X to display a frame from shared memory, for
    > example).

    and yes, video is even more strict about timings.

    > > The patch is trivially simple, like you
    > > can see from the code, and it basically introduces an expiration policy
    > > for realtime tasks (SOFTRR ones).
    > yes, i saw that, pretty nice!
    > i have yet to try it (i don't have any recent 2.5 on my machine)

    It should be trivial to do something like that for the old scheduler.

    > > Patch acceptance is
    > > tricky and definitely would need more discussion and test.
    > Sure. But let me add a voice of support here: I would be great if kernel
    > provided a way to multimedia or interactive applications to request a
    > better latency predictability (or hint the scheduler somehow) without
    > need of being root. If that comes in a form of a new scheduler policy,
    > or just allowing small negative nice values for non-root i don't mind...

    You'd need a nice value that will keep you away from being caught by
    interactive SCHED_OTHER. Otherwise yes, this is another solution. Did you
    try it with xine under high load ?

    - Davide

    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 13:46    [W:0.032 / U:19.184 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site