On Sun, 8 Sep 2002, Ingo Molnar wrote:
> if we didnt disable the IRQ line then an additional interrupt would be
> triggered when [*] is done.
>
> it could perhaps be handled the following way:
>
> disable IRQ line
> ack APIC
> -> call handler
> while (work_left) {
> ack interrupt on the card [*]
> enable IRQ line [**]
> [... full processing ...]
> }
>
> so after [**] is done we could accept new interrupts, and the amount of
> time we keep the irq line disabled should be small. Obviously this means
> driver level changes.
Ok that definitely would allow for more interrupts to get through, i was
working on the basis that handlers with SA_INTERRUPT set would allow for
for that reenable. About the driver level changes, would this be in regard
to a device with ISR_INPROGRESS triggering an interrupt and thus have one
pending? In that case couldn't we avoid touching the driver and increment
a pending counter on that particular handler?
> an additional nit even for edge-triggered interrupts: synchronize_irq()
> needs to be aware of the new bit on SMP, now that IRQ_PENDING is not
> showing the true 'pending' state anymore. But it's doable. Basically
> IRQ_PENDING would be gone completely, and replaced by a more complex set
> of bits in the action struct. In the normal unshared case it should be
> almost as efficient as the IRQ_PENDING bit.
>
> in fact i'd suggest to also add a desc->pending counter in addition to the
> per-action flag, to make it cheaper to determine whether there are any
> pending handlers on the chain.
Gotcha
> also some other code needs to be updated as well to be aware of the
> changed pending-semantics: enable_irq() and probe_irq_on().
I'll have a look at those too.
Thanks,
Zwane
-- function.linuxpower.ca- 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/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:14 EST