Re: [PATCH RFC 2/3] genirq: Honor existing IRQ affinities when setting affinity hints
Jakub Kicinski <[email protected]>
| Newsgroups | dev.linux.lists.linux-rt-devel,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 19 Aug 2026 16:30:31 +0200 Florian Bezdeka wrote: > Some device drivers implement an IRQ balancing / spreading mechanism > based on cpumask_local_spread() and irq_set_affinity_hint() (deprecated) > or irq_set_affinity_and_hint(). Not an expert on IRQs, but this may make the API even more confusing. irq_set_affinity_and_hint() not setting the affinity seems odd. I'd go the other way and either have irq_update_affinity_hint() apply the affinity if it's safe to do so, or create a new function for "defaults". Really, the drivers are dumb here, they are just trying to pass to the core a hint which is: This is Nth of X IRQs, please spread them on the NUMA node where the device is attached. Ideally this (Nth of X) should even be part of request_irq() args. IRQ core already knows the device/NUMA node. Drivers juggling multiple flavors of uAPI-shaped API is... not very scalable. People rarely get this right.