Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sat, 12 Jul 2003 09:30:04 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: [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/
| ![\](/images/icornerr.gif) |