22 Jun
2009
22 Jun
'09
2:26 p.m.
On Mon, 22.06.09 11:53, Paul Davis (paul(a)linuxaudiosystems.com) wrote:
This just isn't true! We had an earlier solution that was working OK
for audio production purposes BUT the kernel folks and embedded linux
developers were not happy about it. RLIMIT_RTPRIO was the result of
some quite extensive and at times heated discussion about how to
replace the old mechanism (based on kernel "capabilities" which have
now mostly gone away) with something else that would work for everyone
that had a stake in the outcome.
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
ever.)
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.
On Mon, Jun 22, 2009 at 11:34 AM, Lennart Poettering<mzynq(a)0pointer.de> 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!]
What exactly are you asking for as
"user-space infrastructure"? Some
easy to reach UI that will allow you to make yourself a member of some
group? This is unlikely to happen. At least not from the desktop
camp.
Well, this is precisely what was imagined when RLIMIT_RTPRIO was added
to the kernel. Even by Ingo :) And no, you don't need to be a member
of a group - limits.conf can grant access on a per-user basis.
What I mean by infrastructure are tools to make RLIMIT_RTPRIO settings
easily configurable by the user. Its still not clear to me how this
works in the case of RTKit either. Are you suggesting that the original decision to focus
on
RLIMIT_RTPRIO was a mistake that didn't take "the reality of what
mainstream distros will do" into account?
Yes. I guess you can say that. Although I wouldn't call it a
"mistake". RLIMIT_RTPRIO was added with audio production in
mind. However, as
soon as we want to make RT available out-of-the-box
RLIMIT_RTPRIO just doesn't cut it.
I'm sorry, I'm still not grasping the idea. Or maybe I am. You're
arguing that because we (will likely) have an RT-sched reset-on-fork
flag, that its now safe to grant RT scheduling permission by
default? First of all, I would dispute that this makes it
"safe" in the sense
you want it to. By this I mean that although theoretically a clone
bomb would be stoppable with a kill(2) call, practically speaking the
machine would be rendered unusable by a suitable clone bomb attack.
That is - without the very things that you say we can't provide right
now - watchdogs,
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
first place.
Please, please with cream on top, read rtkit's README:
http://git.0pointer.de/?p=rtkit.git;a=blob;f=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),
and more. Secondly, if this flag is all that is needed to make it safe
to grant RT scheduling by default, why is RTKit needed at all?
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
scheduling class of interest, which is by no means settled among the
various communities that use RT scheduling.
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
each other.
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
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4