[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&view=markup

Questions?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev