lkml.org 
[lkml]   [2000]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: new IRQ scalability changes in 2.3.48


    On Tue, 29 Feb 2000, Andrea Arcangeli wrote:
    > >It's only necessary for hardware that doesn't work the way we want it to
    > >work.
    >
    > More precisely it's necessary only with edge triggered irqs.

    Indeed. And even then it is only necessary in the case that the edge
    doesn't re-play automatically after an enable() event. For example, on the
    i8259, a disabled interrupt that gets enabled _will_ see an edge if the
    interrupt was active in the first place, because the edge detect logic is
    not on the interrupt line itself, but on the _masked_ interrupt line, so
    unmasking an active interrupt will automatically cause the edge to be
    seen.

    The same is not true on many other edge interrupts (notably the new and
    "improved" IO-APIC is actually de-proved in this respect).


    > That's why in
    > the alpha port I added underlined check to improve performance:

    If you do that, then that just shows that the rest of the interrupt
    subsystem is doing something wrong. You should not have had a pending
    interrupt in normal circumstances in the first place, and the fact that it
    makes a difference for you implies that the alpha "ack()" code is iffy and
    doesn't really synchronize correctly.

    That may be due to a hardware issue, but it's more likely due to you doing
    something wrong in the "mask-and-ack" stage.

    Look at the i386 case for example, for a level interrupt you can do
    either:

    static void mask_and_ack_level_irq (unsigned int i)
    { /* nothing */}

    static void end_level_irq(unsigned int i)
    { hw_ack_irq(); }

    OR you do something like

    static void mask_and_ack_level_irq (unsigned int i)
    { hw_mask_irq(); hw_ack_irq(); }

    static void end_level_irq(unsigned int i)
    { hw_unmask_irq(); }

    but in NO case should the IRQ_PENDING bit be set "extraneously".

    The "PENDING" bit should be meaningful only when there are races between a
    "disable_irq()" and an incoming interrupt, not for normal operations. The
    fact that you needed the hack to avoid taking extra interrupts implies
    that there's something else wrong, and you're just papering it over..

    Linus


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

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