21 Jun
2009
21 Jun
'09
10:01 p.m.
On Sun, 21.06.09 16:06, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) wrote:
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.
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)
Right now you can edit the service startup file and pass them as
command line parameters. Just read the README I linked.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
On Fri, 2009-06-19 at 20:13 +0200, Lennart Poettering wrote:
This is a dep of PA now. Since all major distros adopted PA I'd be
surprised if they wouldn't adopt rtkit too. If things run like they
usually run then this will enter the other distros one cycle past F12.
Heya,
Just a quick announcement:
I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
which will be enabled by default, and since it is now a dependency of
PulseAudio and things work how they work this will then not only be
available in Fedora 12 but also sooner or later in the other
distributions as well, installed by default.
What other distros are considering its use? (or will use it?, or use it
currently?) 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? 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? rtkit enforces
limits on the the number of threads/processes/users
that get RT sched. It also does rate limiting, and calls into
PolicyKit before handing out RT. Finally, as extra a-posteriori
protection it also includes a canary watchdog.
How are all those limits set up and/or configured?