[LAT] [LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA?)

[Fernando Lopez-Lezcano]

On Tue, 2009-02-03 at 16:04 +0100, dieeasy wrote:
> Il giorno Mon, 02 Feb 2009 15:07:58 -0800
> Fernando Lopez-Lezcano <nando at ccrma.Stanford.EDU> ha scritto:
> 
> > > I use "lmms" every now and then. I have never been able to get
> > > "lmms" to work well with jack so I use it with ALSA as the audio
> > > driver. This works fine though I can not use jack application
> > > simultaneously. So in this case do I have to explicitly give "lmms"
> > > SCHED_FIFO and rtprio? How (using chrt?) ?
> > 
> > If you want you could use chrt. I don't know if lmms is multithreaded,
> > if so you would/should change into SCHED_FIFO the audio thread. Even
> > then the application should be well designed, otherwise it could hang
> > the whole machine. 
> 
> 	Hi all,
> 
> I tried lmms using alsa output with SCHED_RR[1] (chrt) and reniced I/O
> (cfq, iorenice) and I found out cpu usage (the one reported by lmms)
> dropped significantly. After rescheduling many tracks that used 100%
> cpu and still clicked got to play nicely with little cpu usage. System
> stability had no issues. LMMS is already threaded and threading support
> is improving with 0.4.x versions[2].
> 
> Having made some experiments with realtime scheduling and after reading
> your words I'll try asking some questions someone here could perhaps
> answer:
> - what's the difference between running some app realtime, say
>   "jackd -R", as opposed to "chrt -r" that same app?[3]

Jack will give SCHED_FIFO to just the audio thread of the client
application (which is normally the only one that actually needs that). 

> - how can I identify the audio thread and change scheduling/nice
>   priority of that single thread?

I don't think you can. You can see the threads and their pids
in /proc/PID/task/ but you don't know which is which. They are just
numbers. 

I pays to have jack applications that are properly designed. Then you
don't have to worry about scheduling and priorities (in a properly
configured system). 

> - given audio threads already are highest priority, isn't it better to
>   also schedule SCHED_RR all audio processes (with lower priority than
>   jackd and other audio threads) so no other process can eat cpu time
>   up?

Audio threads should be the only ones that need realtime scheduling.
What do you mean by "all audio processes"?

> - apart from irq threads, is there any other big improvement a -rt
>   kernel gives over "vanilla"[4] ones?

The time kernel system calls spend in a non-preemptible state are
supposed to be lower than in a stock kernel (but the gap has been
getting narrower). That means that a process that is ready to run and
has SCHED_FIFO has a better chance of being scheduled in time, in the
stock kernel there could be delays in scheduling that cause the process
to be scheduled too late... (and you get an xrun)

> - does enabling "preempt RCU" make a big difference?

I have no idea...

> Sorry if some questions are trivial or already got answered somewhere
> else, I looked around and found nothing relevant concerning these
> questions. I'm not a kernel expert and just digging my way trying
> to learn.
> 
> 
> Bye, Nicola.
> 
> [1] imho SCHED_RR is better than SCHED_FIFO

SCHED_RR will be preempted when it uses up its time slice. That prevents
lockups but it means you could get an xrun anyway. 

> [2]
> http://sourceforge.net/mailarchive/message.php?msg_name=200902020056.29654.tobias.doerffel%40gmail.com
> [3] it seems to me that using chrt to reschedule a process just
>     reschedules one thread, while lanching the same app scheduled with
>     chrt -r in the first place gets all threads scheduled realtime.

I would assume that's how it works. 

You don't want the whole app to be SCHED_FIFO, that would mean that, for
example, screen updates would potentially starve the audio threads. 

> [4] I use "stock" debian kernels reconfigured with forced
>     preemption (low-latency desktop) and 300Hz timer and get pretty low
>     latency (1.5ms) with no xruns at all even under heavy desktop usage

Latest kernels are known to be pretty good without the rt patch. Is this
2.6.28.*? 

-- Fernando