Re: Control of IRQ Affinities from Userspace

[Frederic Weisbecker <frederic@kernel.org>]

Le Tue, Nov 25, 2025 at 12:50:08PM +0100, bigeasy@linutronix.de a écrit :
> On 2025-11-25 12:32:39 [+0100], Florian Bezdeka wrote:
> > > It seems that if you exclude certain CPUs from getting interrupt
> > > handling than it should work fine. Then the driver would only balance
> > > the interrupts among the CPUs that are left.
> > 
> > Sebastian, what exactly do you mean by "exclude certain CPUs from
> > getting interrupt handling"? I mean, that is what we do by configuring
> > the /proc/<irq>/smp_affinity_list interface.
> 
> Step #1
> - figure out if isolcpus= is restricting the affinity of requested
>   interrupts to housekeeping CPUs only
> 
> Step #2
> - Yes
>    => look for the matching knob in cgroup interface
>       Knob found?
>       - Yes
>         => Use knob.
>       - No.
>         => Add knob.
> - No
>   This should be added as it breaks the expectation of an isolated
>   system.
> 
> I *think* the driver should request as many interrupts as there are
> available CPUs in the system to handle them. The number of available
> CPUs/ CPU mask should be a configure knob by the user. Using the
> housekeeping CPUs as a default mask seems reasonable.
> The question is what should happen if the mask changes at runtime. Maybe
> a device needs to reconfigure, maybe just move the interrupt away.
> But this should also affect NOHZ_FULL workloads.

Right now, you still need to change by hand the affinity of an IRQ through
/proc to match a new isolated cpuset partition. But ideally this should be
automatically handled by cpuset. If someone wants to tackle that, it would
be greatly appreciated.

As for those IRQs whose affinity can only be controlled by isolcpus=managed_irq
this is more complicated but probably not unfeasible.

> 
> > To sum up: 
> > - The IRQ balancing issue is not limited to a single driver / subsystem
> > - The managed IRQ infrastructure seems very "static" so insufficient for
> >   this problem. In addition we would have to migrate all affected
> >   drivers to the managed IRQ infrastructure first.
> > 
> > We would love to hear further thoughts / ideas / comments about this
> > problem. We're highly interested in fixing this issue properly.
> 
> If the "managed IRQ infrastructure" would help here then why not. Maybe
> Frederic has some insight here.

Not really but being able to change managed_irq affinities at runtime would
certainly be welcome. I fear my first visit to the genirq subsystem is only
one month old though and I miss the cycles to dive further there right now.

Thanks.

-- 
Frederic Weisbecker
SUSE Labs