[LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

[Fernando Lopez-Lezcano]

On Tue, 2009-06-23 at 13:12 -0400, Paul Davis wrote:
> 2009/6/23 Fernando Lopez-Lezcano <nando at 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