[linux-audio-user] -rt IRQ handler priorities (was: Re: molnar patch)

Wolfgang Hoffmann woho at woho.de
Mon May 8 15:54:53 EDT 2006


On Monday 08 May 2006 20:14, Florian Paul Schmidt wrote:
> On Mon, 8 May 2006 12:03:34 -0500
>
> "Josh Lawrence" <hardbop200 at gmail.com> wrote:
> > fyi, I've followed Dana's instructions more than once and found them
> > to be excellent.  Just use a little common sense when following them
> > (there are newer versions of the kernel and the patch out) and you'll
> > be fine.
> >
> > As Dana mentioned, there's a LOT more to getting realtime working than
> > just the kernel - be sure to read everything there.
>
> I browsed over that page and didn't find any info on setting up the irq
> handler priorities which is _the_ essential feature of -rt.

Apropos: on your page on -rt setup (excellent page, btw., many thanks! :-),
you suggest raising "softirq-timer/0" to prio 99, to make sleep() function 
right (http://tapas.affenbande.org/?page_id=40 sleep() based/system timer).

I did so, and got strange latencies (> 40 ms) exactly once every 10 minutes, 
caused by some routing-related action (rt_secret_rebuild) being run by the 
softirq-timer/0 thread. Don't you get bit by that, too? Kernel is 2.6.16-rt16

My solution is to configure with CONFIG_HIGH_RES_TIMERS=y. Then, sleep() wakes 
up correctly even with softirq-timer/0 being low-priority (SCHED_FIFO 1 or 
even SCHED_OTHER).

In general I find adjusting priorities of the various softirq kernel threads a 
bit of secret art. I can't find much documentation about "what kernel thread 
runs which job" that would help making some proper decisions here. I found my 
desktop "feels" most responsive when demoting all softirq thread to 
SCHED_OTHER. I did so after seeing that with a non-rt kernel, bottom-half 
handler don't run SCHED_FIFO/_RR at all. So -rt now gives me robust low 
latencies for jackd, and still proper desktop feeling.

Well, maybe this is getting off-topic for this list. But it seems to me 
trimming priorities between kernel and userland threads is a bit like no 
man's land.

Wolfgang



More information about the Linux-audio-user mailing list