Still not based on UART_NR. Although Alan said he would take a look at it
next week, because he thinks this is important work.
x86_32 has it set to 1024 so 512 is too small. I think your patch
which essentially restores the old behavior is the right way to go for
this merge window. I just want to carefully look at it and ensure we
are restoring the old heuristics. On a lot of large machines we wind
up having irqs for pci slots that are never filled with cards.
You have noticed how much of those arrays I have collapsed into irq_cfg
on x86_64. We can ultimately do the same on x86_32. The
tricky one is irq_2_pin. I believe the proper solution is to just
dynamically allocate entries and place a pointer in irq_cfg. Although
we may be able to simply a place a single entry in irq_cfg.
Yes. See my patch in the referenced lkml link.
Not when irq_affinity is set. But rather allocate it with the on the
node where the device that generates the irq and the node where the
irq controller the irq goes through is located on. Which is where we
should be handling the irq if we want performance.
I agree with your sentiment if we can actually allocate the irqs by
demand instead of preallocating them based on worst case usage we
should use much less memory.
I figure that keeping any type of nr_irqs around you are requiring
us to estimate the worst case number of irqs we need to deal with.
The challenge is that we have hot plug devices with MSI-X capabilities
on them. Just one of those could add 4K irqs (worst case). 256 or
so I have actually heard hardware guys talking about.
But even one msi vector on a pci card that doesn't have normal irqs could
mess up a tightly sized nr_irqs based soley on acpi_madt probing.
Please read the articles I mentioned. My first approximation would
be a linked list. irq is always defined as "unsigned int irq"
Again in the referenced articles is my old patch that turns kstat.irqs
inside out. Allowing us to handle that case with a normal percpu
allocation per irq. Ultimately I think that is smaller.
Sorry I was referring to the MSI-X source vector number which is a 12
bit index into an array of MSI-X vectors on the pci device, not the
vector we receive the irq at on the pci card.
Eric
--
