RE: [PATCH] x86_64: Make NR_IRQS configurable in Kconfig

Protasevich, Natalie
2006-08-07T16:11:50Z

> > Currrently on a SMP system we can theoretically support
> > NR_CPUS*224 irqs. Unfortunately our data structures don't
> cope will
> > with that many irqs, nor does hardware typically provide
> that many irq
> > sources.
> >
> > With the number of cores starting to follow Moores law, and
> the apicid
> > limits being raised beyond an 8bit number trying to track
> our current
> > maximum with our current data structures would be fatal and
> wasteful.
> >
> > So this patch decouples the number of irqs we support from
> the number
> > of cpus. We can revisit this decision once someone reworks the
> > current data structures.
> >
> > Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> > ---
> > arch/x86_64/Kconfig | 13 +++++++++++++
> > include/asm-x86_64/irq.h | 3 ++-
> > 2 files changed, 15 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig index
> > 7598d99..d744e5b 100644
> > --- a/arch/x86_64/Kconfig
> > +++ b/arch/x86_64/Kconfig
> > @@ -384,6 +384,19 @@ config NR_CPUS
> > This is purely to save memory - each supported CPU requires
> > memory in the static kernel configuration.
> >
> > +config NR_IRQS
> > + int "Maximum number of IRQs (224-4096)"
> > + range 256 4096
> > + depends on SMP
> > + default "4096"
> > + help
> > + This allows you to specify the maximum number of IRQs
> which this
> > + kernel will support. Current maximum is 4096 IRQs as that
> > + is slightly larger than has observed in the field.
> > +
> > + This is purely to save memory - each supported IRQ requires
> > + memory in the static kernel configuration.
>
> If (a) "nor does hardware typically provide that many irq sources"
> and (b) "This is purely to save memory", why is the default
> 4096 instead of something smaller?
>

4k being a humble maximum is definitely a relative term here, but on the
system with "only" 64 or 128 processors the cpu*224 would be much higher
:) However, maybe CONFIG_TINY that Andi suggested would leverage this
number also. What do you think, Eric?

--Natalie