Re: [PATCH 0/7] dyn_array support

[ebiederm@xmission.com (Eric W. Biederman)]

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