22 Jun
2009
22 Jun
'09
11:14 a.m.
On Sun, 21.06.09 20:58, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) wrote:
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.
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
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. 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?