Subject: Re: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
From: Lee Revell (rlrevell_AT_joe-job.com)
Date: Tue Aug 10 2004 - 23:36:47 EEST
On Tue, 2004-08-10 at 16:33, Florian Schmidt wrote:
> On Mon, 09 Aug 2004 17:08:57 -0400
> i get to the conclusion that there indeed was a hierarchy of IRQ's in
> the traditional IRQ handlers in linux. I think this priority is located
> in the PIC itself. I just don't know exactly how to understand the
> implications. Does this priority only apply to irqs which happen to
> happen on the exact same pci bus cycle?
Yes, I think that is all the this means.
> So, if soundcard and hd raise an
> interrupt at the same time, the one with the higher PIC priority gets
> precedence.. All this is still independent of the linux IRQ handlers. I
> assume these PIC priorities still are effective when using threaded IRQ
> handlers.
Yes, because this lives in the hardware. I don't think these priorities
matter much to us.
>
> Now the question is: what happens in linux' traditional IRQ handler?
> Does it honour PIC priorities? Let's assume an ide controller IRQ has
> occured. Linux will handle it by running this irq's handler. This irq
> handler disables further IRQ's from the same ide controller while it
> runs. And reenable them when it finishes. Now during the running of the
> irq handler a soundcard IRQ occurs. What happens?
The disk irq handler will get interrupted by the soundcard, the
soundcard interrupt handler will run, then return control to the disk
interrupt handler. You would think this wouldn't work very well, but
interrupt handlers run quickly, and with further interrupts from the
same source disabled, so interrupt storms do not occur.
However, if it happens the other way, and the disk controller interrupts
the soundcard, this can be a problem, because at the lowest latencies we
have 666 usecs between soundcard interrupts. If the disk controller
interrupts the soundcard and runs for a significant fraction of 666
usecs, then it's possible that by the time control is returned to the
soundcard interrupt handler, we have already missed the next interrupt.
I believe this is what was happening with the earler voluntary
preemption patches (-L2?), where xruns occurred with the default
max_sectors_kb of 1024, but went away when this was lowered to 256.
Lee
This archive was generated by hypermail 2b28 : Tue Aug 10 2004 - 23:39:10 EEST