[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <365dbb61921ff37862c91862d31d75fec2a51185.camel@redhat.com>
Date: Thu, 13 Jul 2023 16:26:53 -0400
From: Radu Rendec <rrendec@...hat.com>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Jingoo Han <jingoohan1@...il.com>,
Gustavo Pimentel <gustavo.pimentel@...opsys.com>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof Wilczynski <kw@...ux.com>,
Rob Herring <robh@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Marc Zyngier <maz@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
Pali Rohár <pali@...nel.org>
Subject: Re: [PATCH 1/1] PCI: dwc: Use regular interrupt instead of chained
On Thu, 2023-07-13 at 12:03 -0500, Bjorn Helgaas wrote:
> On Thu, Jun 29, 2023 at 11:04:50PM -0400, Radu Rendec wrote:
> > On Thu, 2023-06-29 at 17:11 -0500, Bjorn Helgaas wrote:
> > ...
>
> > > If converting from chained to normal handlers can be done safely, I
> > > would definitely be in favor if doing it across all of drivers/pci/ at
> > > once so they're all consistent. Otherwise that code just gets copied
> > > to new drivers, so the issue persists and spreads.
> >
> > I think the conversion can be done safely, meaning that it won't break
> > the drivers. And by the way, there are other IRQ drivers (outside the
> > PCI space) that use chained interrupts.
> >
> > Unfortunately, it seems we are going in circles. Chained interrupts are
> > bad because they let IRQ storms go unnoticed and lock up the system,
> > but converting them to regular interrupts is also bad because it breaks
> > the userspace ABI.
> >
> > I am willing to help clean up this mess, but I think first we need to
> > come up with a solution that's acceptable for everybody. I was hoping
> > Marc and Thomas would chime in, but unfortunately that hasn't happened
> > yet - other than each of them pointing out (separately) what is wrong
> > with each approach.
>
> I don't think Marc or Thomas are going to chime in with a fully-formed
> solution. I think to make progress, you (or Pali, or somebody) will
> have to try to address Marc and Thomas' comments, make a proposal, and
> we can iterate on it.
That crossed my mind too. Unfortunately, Marc's and Thomas' comments
are contradictory, or at least that's my interpretation. I don't expect
them to come up with a fully-formed solution, but merely to agree upon
something that the rest of us can follow. Otherwise, I think no matter
what we may come up with, at least one of them will dismiss it. They
made very clear points, and I understand both. I just can't see a
common denominator.
Let me elaborate a bit. Thomas made it very clear that we should get
rid of chained interrupts altogether and suggested to use regular
interrupts instead. And since all regular interrupts are visible in
procfs by default, so is their affinity control interface. And with
that you can now change the affinity of a parent interrupt and it will
also affect the affinity of all child interrupts. That would break the
promise that the procfs interface currently makes, which is that
setting the affinity on an interrupt will affect *only* that particular
interrupt and nothing else (that is Marc's point).
The only solution that comes to mind is this:
* Add support for tracking parent-child interrupt relationships.
* Modify the existing procfs affinity control interface to reject
changing the affinity of a parent interrupt (i.e. an interrupt that
has at least one child interrupt associated).
* Convert chained interrupts to regular interrupts as needed.
* Create a new sysfs affinity control interface that allows setting
the affinity of any interrupt, including parent interrupts.
* Expose the parent-child interrupt relationships in sysfs, so any
program that is aware of the new interface can go to the root
interrupt to set the affinity.
To be honest, I think this approach would make things even messier and
more confusing than they are today. And I'm not even sure it would not
break the procfs interface backwards compatibility in a different way.
Of course, any comments or suggestions are welcome and would be
appreciated!
Best regards,
Radu
Powered by blists - more mailing lists