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 <[email protected]>
Cc: [email protected]
Cc: "BOBBY Liu (bobbliu)" <[email protected]>
Cc: [email protected]
Signed-off-by: Daniel Walker <[email protected]>
---
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
--
2.25.1
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 <[email protected]>
> Cc: [email protected]
> Cc: "BOBBY Liu (bobbliu)" <[email protected]>
> Cc: [email protected]
> Signed-off-by: Daniel Walker <[email protected]>
> ---
> 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.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
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 <[email protected]>
> > Cc: [email protected]
> > Cc: "BOBBY Liu (bobbliu)" <[email protected]>
> > Cc: [email protected]
> > Signed-off-by: Daniel Walker <[email protected]>
> > ---
> > 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
On Fri, 29 Jul 2022 19:21:56 +0100,
Daniel Walker <[email protected]> wrote:
>
> 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 <[email protected]>
> > > Cc: [email protected]
> > > Cc: "BOBBY Liu (bobbliu)" <[email protected]>
> > > Cc: [email protected]
> > > Signed-off-by: Daniel Walker <[email protected]>
> > > ---
> > > 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.
Which wasn't really acceptable either.
>
> 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.
I don't think you can speak for Thomas here. In my experience of
working with him, he's in general much more inclined to look at a
scalable, long term solution than at a point hack. Specially given
that we already use xarrays for MSIs.
> Your suggestion is more of a long term solution vs. our short term
> solution.
Exactly. Experience shows that short term hacks are almost always a
bad idea and result in something that isn't maintainable.
> 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.
This architecture has been in the wild for the best part of 10 years,
in Linux for 8 years, and nobody so far screamed because of this
perceived limitation. It would help if you described exactly what
breaks in your system, because just saying "give me more" is not
exactly helping (there are other limitations in the GICv3 ITS driver
that may bite you anyway).
> 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.
If you want to have an impact on the features being merged in the
upstream kernel, a good start would be to take feedback on board.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
On Sat, Jul 30, 2022 at 10:59:05AM +0100, Marc Zyngier wrote:
> >
> > Marvell submitted a similar change, but non-selectable, about a
> > month ago.
>
> Which wasn't really acceptable either.
>
> >
> > 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.
>
> I don't think you can speak for Thomas here. In my experience of
> working with him, he's in general much more inclined to look at a
> scalable, long term solution than at a point hack. Specially given
> that we already use xarrays for MSIs.
Your welcome make the attempt yourself, if you believe in it.
> > Your suggestion is more of a long term solution vs. our short term
> > solution.
>
> Exactly. Experience shows that short term hacks are almost always a
> bad idea and result in something that isn't maintainable.
Thomas introduced the "hack" in c1ee626 in 2011.
It's more of a question of if someone has the time an and/or inclination to make the changes
your requesting.
Marvell and Cisco only require to increase the size and keep the status quo, and
nothing is wrong with that.
> > 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.
>
> This architecture has been in the wild for the best part of 10 years,
> in Linux for 8 years, and nobody so far screamed because of this
> perceived limitation. It would help if you described exactly what
> breaks in your system, because just saying "give me more" is not
> exactly helping (there are other limitations in the GICv3 ITS driver
> that may bite you anyway).
We need more irq lines because we have a lot of devices.. I suppose it's
possible there's some defect in the kernel which eats up or wastes irq lines,
but I don't think so. We have devices which use a lot of irq lines.
> > 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.
>
> If you want to have an impact on the features being merged in the
> upstream kernel, a good start would be to take feedback on board.
We did that.. I updated the patch from Marvell's original to allow it to be
selectable, this was requested by someone on this list.
Daniel
On Tue, 02 Aug 2022 23:37:47 +0100,
Daniel Walker <[email protected]> wrote:
>
> On Sat, Jul 30, 2022 at 10:59:05AM +0100, Marc Zyngier wrote:
> > >
> > > Marvell submitted a similar change, but non-selectable, about a
> > > month ago.
> >
> > Which wasn't really acceptable either.
> >
> > >
> > > 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.
> >
> > I don't think you can speak for Thomas here. In my experience of
> > working with him, he's in general much more inclined to look at a
> > scalable, long term solution than at a point hack. Specially given
> > that we already use xarrays for MSIs.
>
> Your welcome make the attempt yourself, if you believe in it.
The thing is, I don't need it, while you apparently do need a change
in the kernel.
>
> > > Your suggestion is more of a long term solution vs. our short term
> > > solution.
> >
> > Exactly. Experience shows that short term hacks are almost always a
> > bad idea and result in something that isn't maintainable.
>
> Thomas introduced the "hack" in c1ee626 in 2011.
Yes. And it covers all the systems we care about so far. It is small,
fixed in size, and doesn't impose extra requirements on everyone else.
Your system changes the requirement, and it is the opportunity to
revisit an 11 year old decision.
> It's more of a question of if someone has the time an and/or
> inclination to make the changes your requesting.
No, it is about who has the need. You do, and nobody else does.
> Marvell and Cisco only require to increase the size and keep the
> status quo, and nothing is wrong with that.
It is pretty wrong when it adds unneeded overhead on systems that
don't require this, and doesn't scale in the face of existing
architectures (let alone future ones). Distributions ship a single
kernel image, and would obviously select the largest possible value,
just to maximise perceived compatibility requirements. My ask is that
you don't inflict this on systems that do not need it.
>
> > > 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.
> >
> > This architecture has been in the wild for the best part of 10 years,
> > in Linux for 8 years, and nobody so far screamed because of this
> > perceived limitation. It would help if you described exactly what
> > breaks in your system, because just saying "give me more" is not
> > exactly helping (there are other limitations in the GICv3 ITS driver
> > that may bite you anyway).
>
> We need more irq lines because we have a lot of devices.. I suppose it's
> possible there's some defect in the kernel which eats up or wastes irq lines,
> but I don't think so. We have devices which use a lot of irq lines.
>
> > > 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.
> >
> > If you want to have an impact on the features being merged in the
> > upstream kernel, a good start would be to take feedback on board.
>
> We did that.. I updated the patch from Marvell's original to allow it to be
> selectable, this was requested by someone on this list.
Well, I'm another "someone on the list" asking you to do better. You
are perfectly entitled to ignore me, and I'm just as entitled to voice
my opposition to your approach.
M.
--
Without deviation from the norm, progress is not possible.
On Wed, Aug 03, 2022 at 08:16:20AM +0100, Marc Zyngier wrote:
> On Tue, 02 Aug 2022 23:37:47 +0100,
> Daniel Walker <[email protected]> wrote:
> >
> > On Sat, Jul 30, 2022 at 10:59:05AM +0100, Marc Zyngier wrote:
> > > >
> > > > Marvell submitted a similar change, but non-selectable, about a
> > > > month ago.
> > >
> > > Which wasn't really acceptable either.
> > >
> > > >
> > > > 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.
> > >
> > > I don't think you can speak for Thomas here. In my experience of
> > > working with him, he's in general much more inclined to look at a
> > > scalable, long term solution than at a point hack. Specially given
> > > that we already use xarrays for MSIs.
> >
> > Your welcome make the attempt yourself, if you believe in it.
>
> The thing is, I don't need it, while you apparently do need a change
> in the kernel.
Do we ? A one line change is not hard to hold in our private tree, I'd rather
not, but it's not hard.
> >
> > > > Your suggestion is more of a long term solution vs. our short term
> > > > solution.
> > >
> > > Exactly. Experience shows that short term hacks are almost always a
> > > bad idea and result in something that isn't maintainable.
> >
> > Thomas introduced the "hack" in c1ee626 in 2011.
>
> Yes. And it covers all the systems we care about so far. It is small,
> fixed in size, and doesn't impose extra requirements on everyone else.
> Your system changes the requirement, and it is the opportunity to
> revisit an 11 year old decision.
Who is "we" in the system cared about ? Are you suggesting there is a certain
set of system Linux supports?
> > It's more of a question of if someone has the time an and/or
> > inclination to make the changes your requesting.
>
> No, it is about who has the need. You do, and nobody else does.
Me, Cisco, and Marvell, and all of our customers isn't "nobody".
> > Marvell and Cisco only require to increase the size and keep the
> > status quo, and nothing is wrong with that.
>
> It is pretty wrong when it adds unneeded overhead on systems that
> don't require this, and doesn't scale in the face of existing
> architectures (let alone future ones). Distributions ship a single
> kernel image, and would obviously select the largest possible value,
> just to maximise perceived compatibility requirements. My ask is that
> you don't inflict this on systems that do not need it.
It adds no un-needed overhead to anyone. It defaults to the current size, if you
make a config change you can increase it. There is no harm to other systems.
> >
> > > > 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.
> > >
> > > This architecture has been in the wild for the best part of 10 years,
> > > in Linux for 8 years, and nobody so far screamed because of this
> > > perceived limitation. It would help if you described exactly what
> > > breaks in your system, because just saying "give me more" is not
> > > exactly helping (there are other limitations in the GICv3 ITS driver
> > > that may bite you anyway).
> >
> > We need more irq lines because we have a lot of devices.. I suppose it's
> > possible there's some defect in the kernel which eats up or wastes irq lines,
> > but I don't think so. We have devices which use a lot of irq lines.
> >
> > > > 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.
> > >
> > > If you want to have an impact on the features being merged in the
> > > upstream kernel, a good start would be to take feedback on board.
> >
> > We did that.. I updated the patch from Marvell's original to allow it to be
> > selectable, this was requested by someone on this list.
>
> Well, I'm another "someone on the list" asking you to do better. You
> are perfectly entitled to ignore me, and I'm just as entitled to voice
> my opposition to your approach.
Sure, We're all entitled to our opinions. Regardless of how terrible they may
be.
Daniel