lkml.org 
[lkml]   [2002]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH][RFC] per isr in_progress markers

    > [...] But your patch is very tempting nevertheless, it removes much of
    > the disadvantage of sharing interrupt lines. Most of the handlers on the
    > chain are supposed to be completely independent.

    one big issue are level triggered interrupts - your approach makes no
    sense in the way we disable/ack the IRQ line currently:

    disable IRQ line
    ack APIC
    -> call handler
    while (work_left) {
    ack interrupt on the card [*]
    [... full processing ...]
    }

    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.


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

    Ingo

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

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