• Natalie Protasevich's avatar
    [PATCH] x86_64: avoid wasting IRQs · 701067c4
    Natalie Protasevich authored
    I suggest to change the way IRQs are handed out to PCI devices.
    
    Currently, each I/O APIC pin gets associated with an IRQ, no matter if the
    pin is used or not.  It is expected that each pin can potentually be
    engaged by a device inserted into the corresponding PCI slot.  However,
    this imposes severe limitation on systems that have designs that employ
    many I/O APICs, only utilizing couple lines of each, such as P64H2 chipset.
    
    It is used in ES7000, and currently, there is no way to boot the system
    with more that 9 I/O APICs.
    
    The simple change below allows to boot a system with say 64 (or more) I/O
    APICs, each providing 1 slot, which otherwise impossible because of the IRQ
    gaps created for unused lines on each I/O APIC.  It does not resolve the
    problem with number of devices that exceeds number of possible IRQs, but
    eases up a tension for IRQs on any large system with potentually large
    number of devices.
    
    I only implemented this for the ACPI boot, since if the system is this big
    and using newer chipsets it is probably (better be!) an ACPI based system
    :).  The change is completely "mechanical" and does not alter any internal
    structures or interrupt model/implementation.  The patch works for both
    i386 and x86_64 archs.  It works with MSIs just fine, and should not
    intervene with implementations like shared vectors, when they get worked
    out and incorporated.
    
    To illustrate, below is the interrupt distribution for 2-cell ES7000 with
    20 I/O APICs, and an Ethernet card in the last slot, which should be eth1
    and which was not configured because its IRQ exceeded allowable number (it
    actially turned out huge - 480!):
    
    zorro-tb2:~ # cat /proc/interrupts
               CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
      0:      65716      30012      30007      30002      30009      30010      30010      30010    IO-APIC-edge  timer
      4:        373          0        725        280          0          0          0          0    IO-APIC-edge  serial
      8:          0          0          0          0          0          0          0          0    IO-APIC-edge  rtc
      9:          0          0          0          0          0          0          0          0   IO-APIC-level  acpi
     14:         39          3          0          0          0          0          0          0    IO-APIC-edge  ide0
     16:        108         13          0          0          0          0          0          0   IO-APIC-level  uhci_hcd:usb1
     18:          0          0          0          0          0          0          0          0   IO-APIC-level  uhci_hcd:usb3
     19:         15          0          0          0          0          0          0          0   IO-APIC-level  uhci_hcd:usb2
     23:          3          0          0          0          0          0          0          0   IO-APIC-level  ehci_hcd:usb4
     96:       4240        397         18          0          0          0          0          0   IO-APIC-level  aic7xxx
     97:         15          0          0          0          0          0          0          0   IO-APIC-level  aic7xxx
    192:        847          0          0          0          0          0          0          0   IO-APIC-level  eth0
    NMI:          0          0          0          0          0          0          0          0
    LOC:     273423     274528     272829     274228     274092     273761     273827     273694
    ERR:          7
    MIS:          0
    
    Even though the system doesn't have that many devices, some don't get
    enabled only because of IRQ numbering model.
    
    This is the IRQ picture after the patch was applied:
    
    zorro-tb2:~ # cat /proc/interrupts
               CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
      0:      44169      10004      10004      10001      10004      10003      10004       6135    IO-APIC-edge  timer
      4:        345          0          0          0          0        244          0          0    IO-APIC-edge  serial
      8:          0          0          0          0          0          0          0          0    IO-APIC-edge  rtc
      9:          0          0          0          0          0          0          0          0   IO-APIC-level  acpi
     14:         39          0          3          0          0          0          0          0    IO-APIC-edge  ide0
     17:       4425          0          9          0          0          0          0          0   IO-APIC-level  aic7xxx
     18:         15          0          0          0          0          0          0          0   IO-APIC-level  aic7xxx, uhci_hcd:usb3
     21:        231          0          0          0          0          0          0          0   IO-APIC-level  uhci_hcd:usb1
     22:         26          0          0          0          0          0          0          0   IO-APIC-level  uhci_hcd:usb2
     23:          3          0          0          0          0          0          0          0   IO-APIC-level  ehci_hcd:usb4
     24:        348          0          0          0          0          0          0          0   IO-APIC-level  eth0
     25:          6        192          0          0          0          0          0          0   IO-APIC-level  eth1
    NMI:          0          0          0          0          0          0          0          0
    LOC:     107981     107636     108899     108698     108489     108326     108331     108254
    ERR:          7
    MIS:          0
    
    Not only we see the card in the last I/O APIC, but we are not even close to
    using up available IRQs, since we didn't waste any.
    Signed-off-by: default avatarNatalie Protasevich <Natalie.Protasevich@unisys.com>
    Acked-by: default avatarAndi Kleen <ak@suse.de>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    701067c4
mpparse.c 24.7 KB