On Mon, 22.06.09 11:53, Paul Davis (paul@email-addr-hidden) wrote:
>
> On Mon, Jun 22, 2009 at 11:34 AM, Lennart Poettering<mzynq@email-addr-hidden> wrote:
> > 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.
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
> >> 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.
>
> 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.)
> > 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?
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
> 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 _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@email-addr-hidden http://lists.linuxaudio.org/mailman/listinfo/linux-audio-devReceived on Mon Jun 22 20:15:08 2009
This archive was generated by hypermail 2.1.8 : Mon Jun 22 2009 - 20:15:08 EEST