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

[Lee Revell]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/