On Tue, 2009-06-23 at 13:12 -0400, Paul Davis wrote: > 2009/6/23 Fernando Lopez-Lezcano <na...@ccrma.stanford.edu>: > > [ ... 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@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev