On Tue, Jun 23, 2009 at 4:15 PM, Fernando
Lopez-Lezcano<na...@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<na...@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)
> 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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
