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

On Sun, 21.06.09 20:58, Fernando Lopez-Lezcano (nando@email-addr-hidden) wrote:

> > > The question is relevant, I think, as the kernels that I use (Planet
> > > CCRMA) are the rt patched kernels, currently limited to 2.6.29.5 (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)

Again, the worst thing that happens is that you need to bump
RLIMIT_RTPRIO for your user, as you always did. rtkit doesn't take
that away.

Summary:

Kernel that lacks SCHED_RESET_ON_FORK: RLIMIT_RTPRIO is what matters.

Kernel that has SCHED_RESET_ON_FORK: RLIMIT_RTPRIO still matters when
it is set, rtkit is used as fallback.

Also note that supporting rtkit often enough doesn't add a build-time
dep to you application and the runtime dependency is very soft too: if
it isn't found it's not used, that's all.

> > > > 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.

In JACK's sources the only place where I see fiddling with the
scheduler is in jack_acquire_real_time_scheduling(), which takes a
pthread_t. pthread_t is process local, so I am pretty sure JACK
doesn't try to change scheduling of out-of-process threads. This
should hence be perfectly compatible with the rtkit model.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev