RE: [(repost) git Patch 1/1] avoid IRQ0 ioapic pin collision

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Natalie,
> Regarding the "IRQ compression" in mp_register_gsi()....
> 
> Some time ago we invented ioapic_renumber_irq() to handle the 
> case where the ES7000 BIOS is missing the INTERRUPT_OVERRIDES 
> needed to tell that legacy IRQs used pins > 15, and PCI 
> interrupts used pins < 16.
> 
> In that case, the ES7000 uses es7000_rename_gsi() to simply 
> re-number the IRQs for the lower pins to some unused numbers 
> above the highest GSI in the system -- emulating what the 
> BIOS should have done.
> 
> Later, GSI compression was also added to mp_register_gsi():
> 
> if (triggering == ACPI_LEVEL_SENSITIVE)
> {
> 	gsi = pci_irq++;
> 	...
> }
> 
> This GSI "compression" was intended to handle systems which 
> have a large number of sparsely populated IOAPICs.  On these 
> systems, the maximum GSI is well above NR_IRQS.  While there 
> can be a large number of devices on these boxes, the total in 
> use is actually still below NR_IRQs -- so squeezing the GSIs 
> into the IRQ numbers works.
> 
> The problem with doing this is that it also compresses the 
> IRQ numbers for the other 99.99% of the systems on earth, 
> causing complexity and bugs, such as several mentioned on this thread.
> 
> I'm thinking that it would be simpler for the big iron that 
> has GSI's > NR_IRQs, to simply use the existing 
> ioapci_renumber_irq() hook to do whatever compression or 
> re-naming they fancy.
> This will also allow for simpler systems to remain simple and 
> use identity irq = gsi numbering.
> (don't get me started on CONFIG_PCI_MSI, that is an independent issue)
> 
> Also, as we discussed, it would probably be cleaner even on 
> those large systems if the compression algorithm did not 
> re-name every GSI, but only did re-names when it really has 
> to (GSI > NR_IRQS).  eg.
> 
> < gsi = pci_irq++
> ---
> > if (GSI < NR_IRQS)
> >    gsi = irq;
> > else
> >    BUG_ON(irq_used >= NR_IRQS)
> >    gsi = platform specific algorithm to grab the unused IRQs that
> >    can never have any real devices attached.
> > irqs_used++;
> 
> If we had done this, then we wouldn't have needed kimbal's patch.
> If we do this, then we can delete that workaround on top of 
> workaround.
> 
> thoughts?

Sure sounds like a great idea. I just signed up for a large partition (>
1700 GSIs) to try this over the weekend.
The problem with oapic_renumber_gsi() is that it didn't actually migrate
to x86_64 because it doesn't have sub-archs so far. But using actual
number of interrupts vs. range is definitely promising idea. I was also
thinking that all the complexity is actually located on the first
IO-APIC, this may have some potential for compression only coming into
play on non-zero IO-APICs. But using the total number of IRQs used is
definitely the most logical thing to try...I will test this shortly -
Thanks, --Natalie 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux