23 Jun
2009
23 Jun
'09
6:27 p.m.
On Tue, Jun 23, 2009 at 4:15 PM, Fernando
Lopez-Lezcano<nando(a)ccrma.stanford.edu> wrote:
On Tue, 2009-06-23 at 15:27 -0400, Paul Davis wrote:
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)
On Tue, Jun 23, 2009 at 2:50 PM, Fernando
Lopez-Lezcano<nando(a)ccrma.stanford.edu> wrote:
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.
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. 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.
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.
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.
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 ... "
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.