Messages in this thread | | | From | (Eric W. Biederman) | Date | Fri, 01 Aug 2008 13:13:45 -0700 | Subject | Re: [PATCH 0/7] dyn_array support |
| |
Ugh. Looks like I forgot to hit send on this.
Yinghai Lu <yhlu.kernel@gmail.com> writes:
> please check the patches adding dyn_array and nr_irqs
YH thank you for working on this.
To fix the post rc1 regression I believe your patch series is very much overkill. We need to fix this but the bug should be fixed first by restoring the old heuristics for NR_IRQS. I will carefully look at your first patch and see if it successfully restores the old heuristics, I don't think it quite does.
I very much do not like this approach of introducing nr_irqs instead of NR_IRQS. It does not kill NR_IRQS it just renames it and it does not appear to me to solve the real issues, and it seems to entrench some current mistakes instead of clean them up. When I said NR_IRQS must die I meant the concept not the spelling. Having a fixed sized array is only part of it. We actually use that array very sparsely. So even having an array of irq_desc structures is painful.
Further we want to user our irq numbers sparsely so that we can have a stable irq numbers even for things such as msis.
Outside of the arch specific code and the irq implementation there are currently only 40 mentions of NR_IRQS, and only 7 mentions of NR_IRQS as an array size.
git-ls-files | grep -v '^arch' | grep -v '^include/asm' | \ grep -v '^kernel/irq' | grep -v 'drivers/xen/events.c' | \ xargs grep '[^A-Za-z0-9_]NR_IRQS[^A-Za-z0-9_]' | wc -l
There is little to no excuse for the generic code to be using NR_IRQS. The usage in /dev/random should be moved in some form into irq_desc. The usage in the serial code and in intr_remapping are failures to use current best practices. For most of the rest simply introducing an irq valid helper function would solve the issue.
Further once we have killed the usage of NR_IRQS outside of the arch code. We don't need to introduce new infrastructure. We can call alloc_bootmem as appropriate, and we can consider important things such as NUMA affinity with the irq controllers, and where we expect the irqs to be serviced.
Plus we don't have to allocate anything beyond the gsi or their mptable equivalents until someone actually uses the msi or htirq interrupt.
Which means we can be a lot leaner, allocating precisely the irqs we need, and a lot more efficient with NUMA affinity and by allocating irqs as they show up.
Eric
| |