On Mon, 2009-06-22 at 20:22 -0400, Paul Davis wrote:
> 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?
Not my understanding at this point. Both limits.conf/PAM/set_rlimits and
rtkit give SCHED_FIFO|SCHED_RR to the process. Rtkit only gives
SCHED_RR(FIFO?) if RLIMIT_RTPRIO is set when the request is made, and
also ||'s the request with the new (forget its name) kernel flag that
resets a process's child to SCHED_OTHER when it forks.
-- Fernando
> 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:09 2009
This archive was generated by hypermail 2.1.8 : Tue Jun 23 2009 - 04:15:09 EEST