Messages in this thread | | | Subject | Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4] | From | Lee Revell <> | Date | Sun, 31 Oct 2004 07:35:09 -0500 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |