Re: [patch] SCHED_SOFTRR linux scheduler policy ...

[Davide Libenzi <davidel@xmailserver.org>]

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