* [PATCH] genirq: allow selection of number of sparse irqs @ 2022-07-28 3:04 Daniel Walker 2022-07-28 8:52 ` Marc Zyngier 0 siblings, 1 reply; 7+ messages in thread From: Daniel Walker @ 2022-07-28 3:04 UTC (permalink / raw) To: Thomas Gleixner Cc: George Cherian, sgoutham, BOBBY Liu (bobbliu), xe-linux-external, linux-kernel 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 -- 2.25.1 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] genirq: allow selection of number of sparse irqs 2022-07-28 3:04 [PATCH] genirq: allow selection of number of sparse irqs Daniel Walker @ 2022-07-28 8:52 ` Marc Zyngier 2022-07-29 18:21 ` Daniel Walker 0 siblings, 1 reply; 7+ messages in thread From: Marc Zyngier @ 2022-07-28 8:52 UTC (permalink / raw) To: Daniel Walker Cc: Thomas Gleixner, George Cherian, sgoutham, BOBBY Liu (bobbliu), xe-linux-external, linux-kernel 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. Thanks, M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] genirq: allow selection of number of sparse irqs 2022-07-28 8:52 ` Marc Zyngier @ 2022-07-29 18:21 ` Daniel Walker 2022-07-30 9:59 ` Marc Zyngier 0 siblings, 1 reply; 7+ messages in thread From: Daniel Walker @ 2022-07-29 18:21 UTC (permalink / raw) To: Marc Zyngier Cc: Thomas Gleixner, George Cherian, sgoutham, BOBBY Liu (bobbliu), xe-linux-external, linux-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] genirq: allow selection of number of sparse irqs 2022-07-29 18:21 ` Daniel Walker @ 2022-07-30 9:59 ` Marc Zyngier 2022-08-02 22:37 ` Daniel Walker 0 siblings, 1 reply; 7+ messages in thread From: Marc Zyngier @ 2022-07-30 9:59 UTC (permalink / raw) To: Daniel Walker Cc: Thomas Gleixner, George Cherian, sgoutham, BOBBY Liu (bobbliu), xe-linux-external, linux-kernel On Fri, 29 Jul 2022 19:21:56 +0100, Daniel Walker <danielwa@cisco.com> 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 <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. 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] genirq: allow selection of number of sparse irqs 2022-07-30 9:59 ` Marc Zyngier @ 2022-08-02 22:37 ` Daniel Walker 2022-08-03 7:16 ` Marc Zyngier 0 siblings, 1 reply; 7+ messages in thread From: Daniel Walker @ 2022-08-02 22:37 UTC (permalink / raw) To: Marc Zyngier Cc: Thomas Gleixner, George Cherian, sgoutham, BOBBY Liu (bobbliu), xe-linux-external, linux-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] genirq: allow selection of number of sparse irqs 2022-08-02 22:37 ` Daniel Walker @ 2022-08-03 7:16 ` Marc Zyngier 2022-08-03 22:44 ` Daniel Walker 0 siblings, 1 reply; 7+ messages in thread From: Marc Zyngier @ 2022-08-03 7:16 UTC (permalink / raw) To: Daniel Walker Cc: Thomas Gleixner, George Cherian, sgoutham, BOBBY Liu (bobbliu), xe-linux-external, linux-kernel On Tue, 02 Aug 2022 23:37:47 +0100, Daniel Walker <danielwa@cisco.com> 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] genirq: allow selection of number of sparse irqs 2022-08-03 7:16 ` Marc Zyngier @ 2022-08-03 22:44 ` Daniel Walker 0 siblings, 0 replies; 7+ messages in thread From: Daniel Walker @ 2022-08-03 22:44 UTC (permalink / raw) To: Marc Zyngier Cc: Thomas Gleixner, George Cherian, sgoutham, BOBBY Liu (bobbliu), xe-linux-external, linux-kernel On Wed, Aug 03, 2022 at 08:16:20AM +0100, Marc Zyngier wrote: > On Tue, 02 Aug 2022 23:37:47 +0100, > Daniel Walker <danielwa@cisco.com> 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-08-03 22:45 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-07-28 3:04 [PATCH] genirq: allow selection of number of sparse irqs Daniel Walker 2022-07-28 8:52 ` Marc Zyngier 2022-07-29 18:21 ` Daniel Walker 2022-07-30 9:59 ` Marc Zyngier 2022-08-02 22:37 ` Daniel Walker 2022-08-03 7:16 ` Marc Zyngier 2022-08-03 22:44 ` Daniel Walker
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.