lkml.org 
[lkml]   [2022]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] genirq: allow selection of number of sparse irqs
On Thu, Jul 28, 2022 at 09:52:18AM +0100, Marc Zyngier wrote:
> On 2022-07-28 04:04, Daniel Walker wrote:
> > Currently the maximum number of interrupters is capped at 8260 (64 +
> > 8196) in most of the architectures were CONFIG_SPARSE_IRQ is selected.
> > This upper limit is not sufficient for couple of existing SoC's from
> > Marvell.
> > For eg: Octeon TX2 series of processors support a maximum of 32K
> > interrupters.
> >
> > Allow configuration of the upper limit of the number of interrupts.
> >
> > Cc: George Cherian <george.cherian@marvell.com>
> > Cc: sgoutham@marvell.com
> > Cc: "BOBBY Liu (bobbliu)" <bobbliu@cisco.com>
> > Cc: xe-linux-external@cisco.com
> > Signed-off-by: Daniel Walker <danielwa@cisco.com>
> > ---
> > kernel/irq/Kconfig | 23 +++++++++++++++++++++++
> > kernel/irq/internals.h | 10 +++++++++-
> > 2 files changed, 32 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
> > index db3d174c53d4..b356217abcfe 100644
> > --- a/kernel/irq/Kconfig
> > +++ b/kernel/irq/Kconfig
> > @@ -125,6 +125,29 @@ config SPARSE_IRQ
> >
> > If you don't know what to do here, say N.
> >
> > +choice
> > + prompt "Select number of sparse irqs"
> > + depends on SPARSE_IRQ
> > + default SPARSE_IRQ_EXTEND_8K
> > + help
> > + Allows choosing the number of sparse irq's available on the
> > + system. For each 8k of additional irqs added there is
> > approximatly
> > + 1kb of kernel size increase.
> > +
> > +config SPARSE_IRQ_EXTEND_8K
> > + bool "8k"
> > +
> > +config SPARSE_IRQ_EXTEND_16K
> > + bool "16K"
> > +
> > +config SPARSE_IRQ_EXTEND_32K
> > + bool "32K"
> > +
> > +config SPARSE_IRQ_EXTEND_64K
> > + bool "64K"
> > +
> > +endchoice
> > +
> > config GENERIC_IRQ_DEBUGFS
> > bool "Expose irq internals in debugfs"
> > depends on DEBUG_FS
> > diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
> > index f09c60393e55..25fe5abf6c16 100644
> > --- a/kernel/irq/internals.h
> > +++ b/kernel/irq/internals.h
> > @@ -12,7 +12,15 @@
> > #include <linux/sched/clock.h>
> >
> > #ifdef CONFIG_SPARSE_IRQ
> > -# define IRQ_BITMAP_BITS (NR_IRQS + 8196)
> > +# if defined(CONFIG_SPARSE_IRQ_EXTEND_8K)
> > +# define IRQ_BITMAP_BITS (NR_IRQS + 8192 + 4)
> > +# elif defined(CONFIG_SPARSE_IRQ_EXTEND_16K)
> > +# define IRQ_BITMAP_BITS (NR_IRQS + 16384 + 4)
> > +# elif defined(CONFIG_SPARSE_IRQ_EXTEND_32K)
> > +# define IRQ_BITMAP_BITS (NR_IRQS + 32768 + 4)
> > +# elif defined(CONFIG_SPARSE_IRQ_EXTEND_64K)
> > +# define IRQ_BITMAP_BITS (NR_IRQS + 65536 + 4)
> > +# endif
> > #else
> > # define IRQ_BITMAP_BITS NR_IRQS
> > #endif
>
> It really feels like the wrong approach. If your system
> supports a large number of interrupt (I guess it has
> a GICv3 ITS), this shouldn't impact the lesser machines
> (most people are using a distro kernel).
>
> It also doesn't really scale: the GICv3 architecture gives
> you up to 24 bits of interrupts. Are we going to allocate
> 2MB worth of bitmap? Future interrupt architectures may have
> even larger interrupt spaces.
>
> As it turns out, we already store the irqdesc in an rb-tree.
> It doesn't take too much imagination to turn this into a
> xarray and use it for both allocation and tracking.
>
> It would also conveniently replace the irqs_resend bitmap
> if using marks to flag the IRQs to be resent.

Marvell submitted a similar change, but non-selectable, about a month ago.

The limitation prevents Cisco and Marvell hardware from functioning. I don't
think we're well versed enough on the generic irq system to implement what your
suggesting, even if we did Thomas would not likely accept it.

Your suggestion is more of a long term solution vs. our short term solution. I'm
not wedded to any solution, we just need to relieve the limitation so our
hardware starts working. I would imagine other companies have this issue, but I
don't know which ones currently.

I would rather to use an upstream solution verses holding the patches privately.
I would suggest if this limitation would not be overcome for 3-4 releases the
short term solution should be acceptable over that time frame to be replaced by
something else after that.

Daniel

\
 
 \ /
  Last update: 2022-07-29 20:24    [W:0.085 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site