Lee Revell:
Subject: Re: -rt IRQ handler priorities (was: Re:
molnar patch)
To: Florian Paul Schmidt <mista.tapas@xxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxx>, linux-audio-user@xxxxxxxxxxxxxxxxxx
Message-ID: <1147129704.9116.21.camel@mindpipe>
Content-Type: text/plain
On Tue, 2006-05-09 at 00:47 +0200, Florian Paul Schmidt wrote:
On Mon, 8 May 2006 21:54:53 +0200
Wolfgang Hoffmann <woho@xxxxxxx> wrote:
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
I haven't been bitten by that. Do you also get xruns with [i suppose so,
just asking to make sure]? I haven't had as much time as before to play
around and test things, so maybe it has crept into the kernel recently
or maybe i just always had high-res timers enabled.
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.
I agree. Maybe Lee Revell knows more [CC'ing him]. Lee, you know
something about all these softirq threads? What exactly do they do?
Not really. The problem with making the softirq timer thread high
priority is that lots of random code gets run from softirq timer
context, including rt_secret_rebuild() which is a well known latency
killer.
Then theres a latency problem in the kernel. A sleeping high priorioty
SCHED_FIFO thread must be woken up in time even if another lower
priority SCHED_FIFO thread is buzy-looping. And currently, unless the
softirq timer has priority 99, that condition can not be fullfilled.
So, the softirq timer must run with priority 99.
