23 Jun
2009
23 Jun
'09
4:49 p.m.
On Tue, 2009-06-23 at 13:12 -0400, Paul Davis wrote:
2009/6/23 Fernando Lopez-Lezcano
<nando(a)ccrma.stanford.edu>du>:
[ ... good attempt at a summary elided ... ]
fernando, unfortunately, you still missed the mechanisms described here:
http://ww2.cs.fsu.edu/~rosentha/linux/2.6.26.5/docs/scheduler/sched-rt-grou…
yes, sorry, I was briefly swallowed into the rtkit-world :-) ...
which are intended to guarantee that an uncontrollable
fork bomb or
runaway process can never happen, and do so without any use of
rlimits. this stuff is in my F10 stock kernel already.
i don't know if lennart will return here
I don't know either, hopefully yes.
to explain why this mechanism
isn't adequate to satisfy distros about enabling RLIMIT_RTPRIO.
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.
Do you have any idea what containers are? No clue here...
It would seem to me that sched-rt-groups (with cgroup support) does
address the problem, but differently. SCHED_RESET_ON_FORK would prevent
the creation of a rt fork bomb, sched-rt-groups + cgroups would just
contain it within the boundaries of the maximum rt time alloted to that
group.
All other issues remain the same (ie: what to do in userland when a
process _is_ eating cpu like crazy). Right?
Yes another issue that has not been raised or explained in the thread
is:
* Client authorization is verified with PolicyKit
What is verified? User account? Other stuff?
-- Fernando