Messages in this thread | | | Date | Sun, 8 Sep 2002 12:38:41 +0200 (SAST) | From | Zwane Mwaikambo <> | Subject | Re: [PATCH][RFC] per isr in_progress markers |
| |
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/
| |