Messages in this thread | | | Date | Tue, 2 Aug 2022 15:37:47 -0700 | From | Daniel Walker <> | Subject | Re: [PATCH] genirq: allow selection of number of sparse irqs |
| |
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
| |