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

From: Lee Revell <rlrevell@email-addr-hidden-job.com>
Date: Tue May 09 2006 - 02:08:24 EEST

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.

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
Received on Tue May 9 08:15:02 2006

This archive was generated by hypermail 2.1.8 : Tue May 09 2006 - 08:15:02 EEST