On Mon, 22.06.09 11:53, Paul Davis (email@example.com) wrote:
This is really the wrong approach. And no other OS does it. Really, how
would you find it if you install Fedora and one of the questions
during installation is whether you want to bump RLIMIT_RTPRIO for your
user, or not? Which user understands what "realtime" means anyway? My
mom certainly doesn't.
Sometimes, there is a bit of disconnect between what kernel folks
think is a good idea and what userspace folks think is one. [Which
(hint hint!) is precisely the reason why plumbers conf is so important
as an attempt to bridge that gap!]
> >> Are you suggesting that the original decision to focus on
Back then audio and embedded realtime folks had a stake in the
outcome. Desktop folks did not, but apparently were expected to add
the "simple" UI for that? I mean, complaining that I now mostly kept
lad out of the loop is not entirely fair if back then you kept desktop
folks out of the loop...
(As a side note: capabilities are still there and doing better than
> > However, as soon as we want to make RT available out-of-the-box
I am arguing that if you have that flag you can set it when handing out
rt sched to other processes in a supervised fashion and be sure that
the process cannot escape your supervision.
> First of all, I would dispute that this makes it "safe" in the sense
As mentioned rtkit implements a watchdog, too. A watchdog however is
an a-posteriori solution to the problem. I.e. when things already
wrong it can be used to fix things up again. rtkit otoh tries to focus
on a-priori solutions, making sure that users cannot misuse RT in the
Please, please with cream on top, read rtkit's README:
Starting at line 39 is the part about watchdogs.
It also roughly explains the problems with the various other
approaches that were tried before.
> resource reservation scheduling (not isochronous),
Because it fixes the problem that is "escaping supervision". Without
the patch a process can easily escape supervision or at least play
race games with the supervisor. rtkit is the supervisor.
> Finally, you seem to continue assuming that SCHED_RR is the only
I have now changed rtkit to make the policy configurable system
wide. I believe the sched policy should be a choice for the admin, not
the developer, as it controls fairness of different RT software to
And again, as I already offered: if someone offers a good real-world
case then we can make the sched policy controllable from the client
side, too, and even the RR qantum, if that's really needed.
However, unless anyone makes a good case how this matters for desktop
applicatios I'd like to start small.
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
Linux-audio-dev mailing list