Re: [linux-audio-user] -rt IRQ handler priorities

Lee Revell:
> Subject: Re: [linux-audio-user] -rt IRQ handler priorities (was: Re:
> molnar patch)
> To: Florian Paul Schmidt <mista.tapas@email-addr-hidden>
> Cc: Ingo Molnar <mingo@email-addr-hidden>, linux-audio-user@email-addr-hidden
> Message-ID: <1147129704.9116.21.camel@email-addr-hidden>
> 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@email-addr-hidden> 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.
Received on Wed May 10 00:15:04 2006