Re: [PATCH RFC 1/3] cpumask: Honor irq_default_affinity in cpumask_local_spread()

[Florian Bezdeka <florian.bezdeka@siemens.com>]

Hi Yury,

On Wed, 2026-08-19 at 14:38 -0400, Yury Norov wrote:
> On Wed, Aug 19, 2026 at 04:30:30PM +0200, Florian Bezdeka wrote:
> > Many drivers call cpumask_local_spread() to spread IRQs to several
> > CPUs, mainly to get best performance and balance CPU load. For
> > realtime (PREEMPT_RT) and other cpu-isolating workloads the old
> > implementation was triggering an IRQ placement problem. IRQs were
> > targeting CPUs that were isolated for those sensitive workloads.
> > 
> > Userland will tell the kernel about the desired IRQ configuration
> > for new interrupts by writing a proper cpumask to
> > /proc/irq/default_smp_affinity. This cpu mask has to be honored to
> > avoid IRQ noise on isolated cores.
> > 
> > The default for irq_default_affinity is "all CPUs". So all CPUs will
> > be taken into account for spreading when userland did not configure
> > something special.
> > ---
> >  lib/cpumask.c | 10 ++++++----
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/lib/cpumask.c b/lib/cpumask.c
> > index 5adb9874fbd0f5a42ea8cd9e6c3729a70599781f..73e7b60a9201174f83df6067effbe7d1889dcdb9 100644
> > --- a/lib/cpumask.c
> > +++ b/lib/cpumask.c
> > @@ -6,6 +6,7 @@
> >  #include <linux/export.h>
> >  #include <linux/memblock.h>
> >  #include <linux/numa.h>
> > +#include <linux/interrupt.h>
> >  
> >  /* These are not inline because of header tangles. */
> >  #ifdef CONFIG_CPUMASK_OFFSTACK
> > @@ -81,8 +82,9 @@ void __init free_bootmem_cpumask_var(cpumask_var_t mask)
> >   * @i: index number
> >   * @node: local numa_node
> >   *
> > - * Return: online CPU according to a numa aware policy; local cpus are returned
> > - * first, followed by non-local ones, then it wraps around.
> > + * Return: online CPU according to the default IRQ affinity and a numa aware
> > + * policy; local cpus are returned first, followed by non-local ones, then it
> > + * wraps around.
> >   *
> >   * For those who wants to enumerate all CPUs based on their NUMA distances,
> >   * i.e. call this function in a loop, like:
> > @@ -110,9 +112,9 @@ unsigned int cpumask_local_spread(unsigned int i, int node)
> 
> Please don't touch this function. There's ~40 users, and we don't want
> to inspect every caller for their intention.

Yes and no.

Yes: Your suggestions / concerns are valid. Noted.

No: I'm expecting a revisit of all those usages. All "affected" drivers
need to be fixed / addressed at the end, so we have to check all of them
and migrate them.

Sebastian also commented on this meanwhile. I'm fine with migrating
affected drivers one by one. Makes sense.

But before we start the migration process I'm still missing the "plan"
or "vision". Which way do we want to go? Let's see if there is more
input coming.

Should drivers really deal with those cpumasks? I don't think so - at
the moment.

Thanks, highly appreciated.

Florian