On 4/10/07, Pieter Palmers <pieterp@xxxxxxx> wrote:
Florian Schmidt wrote: > On Tuesday 10 April 2007, Pieter Palmers wrote: > >> The IRQ handler 'vectors' are called by the hardware, and these call the >> IRQ handler functions registered in the kernel. Ingo's patch makes these >> handler functions run in separate threads that are scheduled at a >> certain priority. These IRQ handler functions then determine what module >> the IRQ is for/from, and run the IRQ handler for that module, at the >> same priority as it was scheduled itself. >> >> What I propose is that the IRQ handler priority can be set for each >> module irq handler, instead of for each 'global' irq handler. > > Yes, that would be nice. I'm pretty sure Ingo thought of this before himself. me too actually ;) > I suspect practical reasons [i.e. too much work] for this not being > implemented. Am i right, Ingo [CC'ed]? I don't think it's that much work, but there might be caveats that are not really apparent on first sight. If this isn't the case, I might try and cook up a patch that can trigger the open source process.
I don't think this would help - with threaded interrupts the kernel masks the irq then schedules the handler thread which runs the registered handlers in sequence, one of which will acks and unmask it. The kernel does not know which device generated the interrupt nor is there a generic mechanism to ack an irq - only the drivers knows how to do this. So priortizing the handlers for different devices on the same line buys you nothing - if the firewire hardware interrupts, no other irqs on that line can be serviced until the firewire ISR has run and acked the IRQ. Excessively shared interrupts are a legacy hardware problem, you'll never solve it in software. The solution is APIC and MSI and the like. There is a potential for microoptimization: currently when a shared IRQ is raised the kernel runs all the registered handlers in the order they were registered (aka driver load order). So it's possible for another driver on the same IRQ to delay the handling of time critical IRQs if it takes a long time for the ISR to determine whether it's device generated this interrupt. This could be improved by extending the meaning of SA_INTERRUPT flag to insert this handler at the head of the chain. Lee _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
