On Mon, Jun 22, 2009 at 8:05 PM, Lennart Poettering<mzynq@email-addr-hidden> 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 ...
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Jun 23 04:15:08 2009
This archive was generated by hypermail 2.1.8 : Tue Jun 23 2009 - 04:15:08 EEST