lkml.org 
[lkml]   [2003]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 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 13:46    [W:0.057 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site