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

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Tue Jun 23 00:50:15 UTC 2009


On Mon, 2009-06-22 at 20:22 -0400, Paul Davis wrote:
> 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?

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 ...
> _______________________________________________





More information about the Linux-audio-dev mailing list