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

[Paul Davis]

On Mon, Jun 22, 2009 at 8:05 PM, Lennart Poettering<mzynq at 0pointer.de> wrote:
> You are misunderstanding what I was saying: either a process is
> SCHED_RR/FIFO or it is not. That's a binary thing. Either you get the
> full RT powers, or no RT powers at all. Desktop media stuff doesn't
> need the full RT powers.

now i'm even more confused. there are two properties we seem to be
discussing. one is which scheduling class a thread is in. the other is
whether the process has RLIMIT_RTPRIO set. you're saying that RTKit
puts the thread into the/a RT scheduling class, whereas
limits.conf/PAM/set_rlimits gives it RLIMIT_RTPRIO. correct?

a few more questions now that i've read the README once (more to come):

1) do you have a plan for mlock/mlock_all ?

2) if a distro decides they want RTKit around, why not set
SCHED_RESET_ON_FORK for init, thus preventing a fork bomb ever, and
run the watchdog as part of the regular startup process? why start it
on demand? then allow any process to obtain SCHED_FIFO/RR, knowing
that its now "safe" ?

3) in your README you claim "If processes that have real-time
scheduling privileges enter a busy loop they can freeze the entire the
system." But this seems to ignore the existence of :
/proc/sys/kernel/{sched_rt_period_us,sched_rt_runtime_us} which i
understood as preventing this without any other kernel mechanisms? I
quote from: http://ww2.cs.fsu.edu/~rosentha/linux/2.6.26.5/docs/scheduler/sched-rt-group.txt

"These defaults were chosen so that a run-away realtime tasks will not
lock up the machine but leave a little time to recover it."

so now i'm even more puzzled about what problem you are attempting to solve ...