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

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Sun Jun 21 23:06:44 UTC 2009


On Fri, 2009-06-19 at 20:13 +0200, Lennart Poettering wrote:
> 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). 

> You
> 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?

-- Fernando





More information about the Linux-audio-dev mailing list