On Tue, 2009-06-23 at 15:27 -0400, Paul Davis 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.
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
Merged != Beautiful :-) I did not want to comment on that part
initially. He does not say "the API is not usable for the purpose at
hand" but rather "it is horrible", which is a subjective thing. It may
be horrible (and that is what it looks like from a brief look at
Documentation/cgroups.txt - try it), but usable. Or may be horrible and
not usable, we don't know.
> Its already wierd enough to have RLIMIT_RTPRIO and RTKit both capable
I don't know enough to comment on this. It could be a "not invented
here" thing, or there could be sound technical reasons (the "non-obvious
consequences" he does not dwell on or explain).
> > Do you have any idea what containers are? No clue here...
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)... If
the clone bomb is still an issue then the whole SCHED_RESET_ON_FORK
concept seems less than useful. Ingo was also involved so I imagine they
thought about this thoroughly? On the other hand it would not be the
first time Ingo just replaces a whole kernel subsystem from scratch
(usually with a nice outcome :-)
Argh. I should try to find the SCHED_RESET_ON_FORK thread(s) on lkml to
see what was argued.
> whereas in the stuff
Yes, it is debatable. I would put mechanisms for policy in the kernel
and the policy itself in userspace.
> of course, the scheduler won't actually kill the offender, and
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.
Looks to me like there are too many questions that only Lennart can
Linux-audio-dev mailing list