Re: [patch 1/1] Proposed: Let's not waste precious IRQs...

[Zwane Mwaikambo]

Hi Natalie,

On Thu, 19 May 2005 Natalie.Protasevich@xxxxxxxxxx wrote:

> 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

Can you determine number of slots in use?

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

Well we ran into similar problems on older MPS systems (NUMAQ) but those 
don't really matter right now anyway. So i think fixing this for ACPI is 
fine.

But i like your patch =)

Thanks,
	Zwane

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