On Mon, 8 May 2006 21:54:53 +0200
Wolfgang Hoffmann <woho(a)woho.de> 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.
Lately I've been focused on getting mainline usable for audio - I have
not run -rt in a while.
It is a bit of a black art because you need lots of knowledge of the
kernel to know how to set the priorities. But that's the nature of hard
realtime - you really need to know a lot about the system to get the
priorities right.
I've never had to alter the priority of the softirq timer thread myself
- does it work OK if you leave the softirq thread alone?
If not try setting the softirq thread to a lower RT priority than your
soundcard, JACK, and all other interrupt threads.
I've added Ingo to the cc: list, maybe he has some input.
Lee