Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]

Lee Revell
2004-10-31T12:35:17Z

On Sun, 2004-10-31 at 13:19 +0100, Ingo Molnar wrote:
> we could do this too. The reason why i picked the current "start at
> SCHED_FIFO prio 49 and decrease it by 1 until it reaches 25, then stay
> constant" logic is that typically the irqs registered first are 'more
> important' - e.g. the timer interrupt.

Hmm, maybe the timer interrupt should be 99 and the rest say 50.
Wouldn't it be bad if you had a fully loaded jackd (DSP load in JACK is
the proportion of the process cycle to the period time; in a fully
loaded jack setup the clients are using all the available time) and
jackd + the soundcard IRQ's RT priorities are higher than the timer
interrupt? Seems like you could starve the timer interrupt
indefinitely.

In fact, the only IRQ thread that currently _needs_ to be lower prio
than the others is IDE - the others all execute quickly enough to only
cause a problem at _extreme_ latencies that you would never use in the
real world, at least for audio/JACK. Last time I checked no other
hardirq ran for more than about 50 usecs. With Jens' patch to move IDE
bh processing into a softirq, I suspect the relative priorities of the
IRQ threads would not matter at all.

Lee