On Tue, 2009-06-23 at 13:12 -0400, Paul Davis wrote:
> 2009/6/23 Fernando Lopez-Lezcano <nando@email-addr-hidden>:
>
> [ ... 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-group.txt
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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Jun 24 00:15:04 2009
This archive was generated by hypermail 2.1.8 : Wed Jun 24 2009 - 00:15:04 EEST