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

Steven, can you suggest a way forward? Briefly the problem is that
arbitrary latency killing code can run from the softirq timer thread,
but this thread needs to run at max RT priority for sleep(), select() &
friends to work.

I guess it hasn't been a problem yet because most RT threads want to be
awakened by some external event like an interrupt, rather than a timer.

Lee

On Tue, 2006-05-09 at 12:56 -0700, Kjetil S. Matheussen wrote:
> 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