[lkml]   [2002]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.


> 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.190 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site