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

[Fernando Lopez-Lezcano]

[something appears to be wrong on the list, I'm not seeing your posts
there, I'm just getting the emails directly addressed to me]

On Tue, 2009-06-23 at 16:27 -0400, Paul Davis wrote:
> On Tue, Jun 23, 2009 at 4:15 PM, Fernando
> Lopez-Lezcano<nando at ccrma.stanford.edu> wrote:
> > On Tue, 2009-06-23 at 15:27 -0400, Paul Davis wrote:
> >> On Tue, Jun 23, 2009 at 2:50 PM, Fernando
> >> Lopez-Lezcano<nando at ccrma.stanford.edu> wrote:
> >> >
> >> > This is what Lennart wrote in his original announcement:
> >> >
> >> >> 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.
> >>
> >> The problem with this is that the mechanism described there is
> >> actually not dependent on the use of cgroups at all. It will limit all
> >> !SCHED_OTHER threads whether they are in a cgroup or not.
> >
> > Not my reading of it. The default 100%/95% split will be allocated to
> > root only (the only entity - this is not a group or a cgroup - that is
> > there by default). My understanding is that non-root users will not be
> > able to run realtime unless that is changed from the default (even if
> > other mechanism allows them to run rt). I don't know how you enable the
> > whole thing in the first place.
> 
> you are right. my initial reading was that "root group" in this
> context had little to do with "root" in the traditional sense of uid=0
> and more to do with "root of the filesystem" i.e. the root group is
> the parent of all other cgroups. but it goes on to say "Therefore you
> will not be able to run realtime tasks as any user other than root
> until you have done that, even if the user has the rights to run
> processes with realtime priority!"
> 
> i am also a little confused by what the default values mean (run time = 0)

I think that means that if you create a new group (whatever that is -
I'm not sure at this point) and do nothing, the member (whatever they
are) will not be able to run rt. You have to first set the root group to
something smaller and then allocate that to the new group. 

> > The document provides two ways of reallocating realtime real state
> > (configurable at build time), one by uid and the other by using
> > cgroup's. So, yes, you apparently depend on cgroups to get the
> > functionality.
> 
> true, but what i actually meant was that the measurement and limit
> system is in place with or without cgroups.

But is does not seem to be usable without them.
But but.. but....

For example, in the kernel I'm running (2.6.29.5 + rt21):
$ cat /proc/sys/kernel/sched_rt_period_us
1000000
$ cat /proc/sys/kernel/sched_rt_runtime_us
950000

So that part is there and configured. And:
CONFIG_CGROUP_SCHED=y
And furthermore:
CONFIG_RT_GROUP_SCHED=y
see here for an interesting entry:
  https://bugzilla.redhat.com/show_bug.cgi?id=442959
and
  http://bugzilla.kernel.org/show_bug.cgi?id=10361
  (referenced inside the previous ticket)
this is when it was apparently added to the Fedora kernels:
--------
* Fri Apr 18 2008 Kyle McMartin <kmcmartin at redhat.com> - 
Enable CONFIG_RT_GROUP_SCHED (#442959)
--------

There's something else I'm missing because I'm still able to run rt as a
non-root user even though I have all this stuff. Is Fedora configuring
this somewhere else? Is this overriden by something else?

> the API looks entirely usable to me, in the sense that i could easily
> imagine a GUI control panel for this that would be comprehensible to
> most users.

I think the idea is no control panel :-)

> > Hmmm, did Lennart specifically answer the issue of the clone bomb? I
> > can't remember and the thread is looong (I had a couple of points that I
> > made that seemed to be valid and never got a confirmation reply)...
> 
> i   believe he claimed the watchdog deals with this. it was pointed
> out that all you need to do is to know the rule the watchdog uses and
> you can still pretty effectively lock the machine from the perspective
> of a non-CS-y user.

If that is the case then I don't know what is the use of
SCHED_RESET_ON_FORK. I am missing something. Is a clone something harder
to do than a fork? It appears to be the same amount of programming
effort. So, if SCHED_RESET_ON_FORK works on fork and not clone, and it
is possible to make a clone bomb then SCHED_RESET_ON_FORK is worthless
(IMHO), as a clone bomb's effect would be the same as the fork bomb's
effect AFAICT and then why not deal with both using the same mechanism
rather that _adding_ something to the kernel. I definitely _have_ to be
missing something. 

> here's my halfway (?) summary:
> 
>    "distros refuse to even provide a way to enable RLIMIT_RTPRIO because
>      it enables regular users to lockup the machine.
> 
>     Up next: 8 other ways for regular users to easily lockup the machine ... "

Lock up a machine? As in hang it? I don't imagine it is _that_ easy. I
guess you could use up all memory and eventually get the machine
completely catatonic. And then the oom killer kicks in and something
random that uses memory dies...

> > I don't know either. In either case the watchdog would probably be
> > running with the highest rt priority so it should be scheduled in as
> > fast in one as in the other. Probably faster when what needs to be
> > killed is SCHED_OTHER.
> 
> I don't believe that the RTKit watchdog (like Kjetil's Das Watchdog)
> takes any action against any SCHED_OTHER process.

Ah, yes.
-- Fernando