Date:   Wed, 3 Aug 2022 15:44:55 -0700
From:   Daniel Walker <danielwa@...co.com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        George Cherian <george.cherian@...vell.com>,
        sgoutham@...vell.com, "BOBBY Liu (bobbliu)" <bobbliu@...co.com>,
        xe-linux-external@...co.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] genirq: allow selection of number of sparse irqs

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@...co.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

Powered by blists - more mailing lists