On Sun, 21.06.09 20:58, Fernando Lopez-Lezcano ([email protected]) 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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
