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

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. So what does this do? It's a simple policy daemon that hands out SCHED_RR scheduling to normal user processes/threads that ask for it. So what's so fancy about it? Nothing. Except that is hopefully a good solution for handing out RT scheduling and is also actually secure. What's wrong with using RLIMIT_RPRIO? The simple fact that we cannot enable that by default since it basically empowers the user to freeze the machine. Also, asking the user to edit /etc/security/limits.conf is certainly not user-friendly. We want to enable RT scheduling for media aplications out-of-the-box. But what's wrong with relying on RLIMIT_RTTIME? Being a process limit it can very easily be circumvented for freezing the machine by combining an RT busy loop with a fork bomb. But what's wrong with relying on on a canary watchdog to avoid freezing systems? It's racy: an evildoer could fork more quickly than the canary watchdog daemon could demote its children. So a canary is not really a protection against a frozen system. Why not use cgroups for this? Because it's simply a horrible API, and using this for media applications has non-obvious consequences on using cgroups for their originally intended purpose -- which are containers. 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. 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. 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. So what does that mean for you? If you don't do RT development or doing RT development only for embedded cases, or if you are a Gentoo-Build-It-All-Myself-Because-It-Is-So-Much-Faster-And-Need-To-Reinvent-The-Wheel-Daily-And-Configurating-Things-Is-Awesome-Guy then it doesn't mean anything for you. However, if you are a desktop developer interested to get your stuff working out-of-the-box on modern distributions then you should think about calling into RealtimeKit for acquiring RT scheduling. RealtimeKit has a trivial API, to make a thread SCHED_RR it's just one D-Bus method you need to call. You can either code that call yourself or alternatively just copy the reference client implementation rtkit includes into your sources: http://git.0pointer.de/?p=rtkit.git;a=blob;f=rtkit.h http://git.0pointer.de/?p=rtkit.git;a=blob;f=rtkit.c For more information see this: http://git.0pointer.de/?p=rtkit.git;a=blob;f=README So yepp, it would be great if folks would adopt this in their apps, so that a user doesn't need to know about all those Unix intricacies such as resource limits and so on, but still get good perfomance in his media applications by default. This is now in Fedora Rawhide which will still take a few months to be released as F12. The other distros probably need a bit more time for this. This means this is not a burning issue yet, so this is mostly intended as a heads-up right now. Unless of course you are one of those cool dudes who are living on the bleeding edge. Packagers, you might want to steal this .spec file for you work: http://cvs.fedoraproject.org/viewvc/devel/rtkit/rtkit.spec?revision=1.1&… Questions? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4