.../pci/controller/dwc/pcie-designware-host.c | 123 ++++++++---------- drivers/pci/controller/dwc/pcie-designware.h | 7 +- include/linux/irq.h | 6 + include/linux/irqdesc.h | 11 +- kernel/irq/chip.c | 20 +++ kernel/irq/irqdesc.c | 51 +++++++- kernel/irq/manage.c | 16 ++- 7 files changed, 154 insertions(+), 80 deletions(-)
Various attempts have been made so far to support CPU affinity control for (de)multiplexed interrupts. Some examples are [1] and [2]. That work was centered around the idea to control the parent interrupt's CPU affinity, since the child interrupt handler runs in the context of the parent interrupt handler, on whatever CPU it was triggered. This is a new attempt based on a different approach. Instead of touching the parent interrupt's CPU affinity, the child interrupt is allowed to freely change its affinity setting, independently of the parent. If the interrupt handler happens to be triggered on an "incompatible" CPU (a CPU that's not part of the child interrupt's affinity mask), the handler is redirected and runs in IRQ work context on a "compatible" CPU. This is a direct follow up to the (unsubmitted) patches that Thomas Gleixner proposed in [3]. The first patch adds support for interrupt redirection to the IRQ core, without making any functional change to irqchip drivers. The other two patches modify the dwc PCI core driver to enable interrupt redirection using the new infrastructure added in the first patch. Thomas, however, I made a small design change to your original patches. Instead of keeping track of the parent interrupt's affinity setting (or rather the first CPU in its affinity mask) and attempting to pick the same CPU for the child (as the target CPU) if possible, I just check if the child handler fires on a CPU that's part of its affinity mask (which is already stored anyway). As an optimization for the case when the current CPU is *not* part of the mask and the handler needs to be redirected, I pre-calculate and store the first CPU in the mask, at the time when the child affinity is set. In my opinion, this is simpler and cleaner, at the expense of a cpumask_test_cpu() call on the fast path, because: - It no longer needs to keep track of the parent interrupt's affinity setting. - If the parent interrupt can run on more than one CPU, the child can also run on any of those CPUs without being redirected (in case the child's affinity mask is the same as the parent's or a superset). Last but not least, since most of the code in these patches is your code, I took the liberty to add your From and Signed-off-by tags to properly attribute authorship. I hope that's all right, and if for any reason you don't want that, then please accept my apologies and I will remove them in a future version. Of course, you can always remove them yourself if you want (assuming the patches are merged at some point), since you are the maintainer :) [1] https://lore.kernel.org/all/20220502102137.764606ee@thinkpad/ [2] https://lore.kernel.org/all/20230530214550.864894-1-rrendec@redhat.com/ [3] https://lore.kernel.org/linux-pci/878qpg4o4t.ffs@tglx/ Radu Rendec (3): genirq: Add interrupt redirection infrastructure PCI: dwc: Code cleanup PCI: dwc: Enable MSI affinity support .../pci/controller/dwc/pcie-designware-host.c | 123 ++++++++---------- drivers/pci/controller/dwc/pcie-designware.h | 7 +- include/linux/irq.h | 6 + include/linux/irqdesc.h | 11 +- kernel/irq/chip.c | 20 +++ kernel/irq/irqdesc.c | 51 +++++++- kernel/irq/manage.c | 16 ++- 7 files changed, 154 insertions(+), 80 deletions(-) -- 2.51.0
+ folks who were part of previous attempts On Fri, Oct 03, 2025 at 12:04:18PM -0400, Radu Rendec wrote: > Various attempts have been made so far to support CPU affinity control > for (de)multiplexed interrupts. Some examples are [1] and [2]. That work > was centered around the idea to control the parent interrupt's CPU > affinity, since the child interrupt handler runs in the context of the > parent interrupt handler, on whatever CPU it was triggered. > > This is a new attempt based on a different approach. Instead of touching > the parent interrupt's CPU affinity, the child interrupt is allowed to > freely change its affinity setting, independently of the parent. If the > interrupt handler happens to be triggered on an "incompatible" CPU (a > CPU that's not part of the child interrupt's affinity mask), the handler > is redirected and runs in IRQ work context on a "compatible" CPU. This > is a direct follow up to the (unsubmitted) patches that Thomas Gleixner > proposed in [3]. > > The first patch adds support for interrupt redirection to the IRQ core, > without making any functional change to irqchip drivers. The other two > patches modify the dwc PCI core driver to enable interrupt redirection > using the new infrastructure added in the first patch. > > Thomas, however, I made a small design change to your original patches. > Instead of keeping track of the parent interrupt's affinity setting (or > rather the first CPU in its affinity mask) and attempting to pick the > same CPU for the child (as the target CPU) if possible, I just check if > the child handler fires on a CPU that's part of its affinity mask (which > is already stored anyway). As an optimization for the case when the > current CPU is *not* part of the mask and the handler needs to be > redirected, I pre-calculate and store the first CPU in the mask, at the > time when the child affinity is set. In my opinion, this is simpler and > cleaner, at the expense of a cpumask_test_cpu() call on the fast path, > because: > - It no longer needs to keep track of the parent interrupt's affinity > setting. > - If the parent interrupt can run on more than one CPU, the child can > also run on any of those CPUs without being redirected (in case the > child's affinity mask is the same as the parent's or a superset). > > Last but not least, since most of the code in these patches is your > code, I took the liberty to add your From and Signed-off-by tags to > properly attribute authorship. I hope that's all right, and if for any > reason you don't want that, then please accept my apologies and I will > remove them in a future version. Of course, you can always remove them > yourself if you want (assuming the patches are merged at some point), > since you are the maintainer :) > > [1] https://lore.kernel.org/all/20220502102137.764606ee@thinkpad/ > [2] https://lore.kernel.org/all/20230530214550.864894-1-rrendec@redhat.com/ > [3] https://lore.kernel.org/linux-pci/878qpg4o4t.ffs@tglx/ > > Radu Rendec (3): > genirq: Add interrupt redirection infrastructure > PCI: dwc: Code cleanup > PCI: dwc: Enable MSI affinity support > > .../pci/controller/dwc/pcie-designware-host.c | 123 ++++++++---------- > drivers/pci/controller/dwc/pcie-designware.h | 7 +- > include/linux/irq.h | 6 + > include/linux/irqdesc.h | 11 +- > kernel/irq/chip.c | 20 +++ > kernel/irq/irqdesc.c | 51 +++++++- > kernel/irq/manage.c | 16 ++- > 7 files changed, 154 insertions(+), 80 deletions(-) > > -- > 2.51.0 > -- மணிவண்ணன் சதாசிவம்
© 2016 - 2025 Red Hat, Inc.