[LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Mon Jun 22 03:58:31 UTC 2009

On Mon, 2009-06-22 at 02:01 +0200, Lennart Poettering wrote:
> On Sun, 21.06.09 16:06, Fernando Lopez-Lezcano (nando at ccrma.Stanford.EDU) wrote:
> > > So what does RealtimeKit do that previous solutions didn't do? rtkit
> > > relies on a new kernel feature SCHED_RESET_ON_FORK that got recently
> > > merged into Ingo's tree and will hence shortly appear in 2.6.31. 
> > 
> > So this is, at this point, kernel version dependent, right? 
> > What happens if you run a 2.6.29.x kernel?
> Nothing. Then the call into rtkit will simply fail. Since the rtkit
> call is intended to be used as fallback only things will work as well
> or badly as they did before rtkit was introduced.
> > The question is relevant, I think, as the kernels that I use (Planet
> > CCRMA) are the rt patched kernels, currently limited to (I
> > think Thomas and the rt gang are working on 2.6.30, I imagine 2.6.31
> > support is still far in the future). 
> Dunno. I disagree. The primary objective for rtkit is to be able to
> run media applications as RT by default, out-of-the-box. I doubt that
> this feature matters for legacy distros/kernels.

I'm talking about the rt kernels specifically. In that context users
don't have a real choice as to what they get to run and the meaning of
legacy is different (I understand you may not care because of the target
audience of PA, but then again the RealtimeKit is being proposed as a
generic solution for access to rt scheduling). 

If the rt patch does not catch up fast enough then I may need to run a <
2.6.31 kernel (whatever is available at the time) in Fedora 12 when it
is released, hardly a legacy distro :-) 

(maybe unlikely, but it would not be the first time rt development
stalls for a looong time and you can't run the latest and greatest - not
complaining, just a fact)

> > > can set that flag when entering SCHED_RR scheduling and this will
> > > then make sure that after forking a child will be reset to
> > > SCHED_OTHER. RT fork bombs can thus be made impossible: if we hand
> > > out RT to a process we can be sure it won't "leak", and if we
> > > decide to take it away again we can be sure we can do that without
> > > having to be afraid of races around forking.
> > 
> > If I understand correctly then the mechanism would not be useful for
> > jack (leaving aside the issue of SCHED_RR vs. SCHED_FIFO), as jack
> > actually gives rt priority to threads in other processes (the clients of
> > jack). But maybe things have changed in the way jack works internally
> > these days, or, possibly I'm not completely understanding the
> > implications... hmmmmm... jack does not do any forking right? 
> Dunno. All processes that want to have rt need to ask rtkit
> themselves. (which is the only safe thing to do, only then we get the
> credentials properly defined)

We should try to find out what happens in Jack's case. 

It would be a __MAJOR__ step back if RealtimeKit is not usable by Jack
and it becomes the way distributions (and in particular Fedora) give
out-of-the-box access to rt scheduling. 

-- Fernando

More information about the Linux-audio-dev mailing list