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
