22 Jun
2009
22 Jun
'09
10:22 p.m.
On Mon, Jun 22, 2009 at 8:05 PM, Lennart Poettering<mzynq(a)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-grou…
"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 ...