Re: Control of IRQ Affinities from Userspace

["bigeasy@linutronix.de" <bigeasy@linutronix.de>]

On 2025-11-21 13:25:09 [+0000], Preclik, Tobias wrote:
> > I would be careful with the deprecated term here. The functionality
> > is
> > not deprecated just the interface is. The CPU affinity has been
> > migrated
> > a cgroup based interface. If the matching irq affinity is missing
> > then
> > it should be added rather than avoiding the whole "affinity is
> > managed"
> > interface since this looks as it has been meant for your use case.
> > 
> 
> As you point out isolcpus interface is deprecated and it seems there
> exists no way to translate the managed_irq flag of the isolcpus
> interface into the cgroups based interface. My understanding is that

I did not point out anything. I just suggested to test whether this
option is working for you and if it does, check if there is matching
configuration knob in the cpusets/cgroups interface. As per 
   https://www.suse.com/c/cpu-isolation-practical-example-part-5/

in "3.2) Isolcpus" Frederic says that the options should be used if the
kernel/ application "haven't been built with cpusets/cgroups support".
So it seems that this bit is either missing in the other interface or
hard to find.

…
> > > The conclusion got lost:
> > >
> > > Other drivers like for example igb respect the interrupt affinities
> > > (both default and per-irq affinities). This leads me to believe
> > that
> > > the irq rebalancing in the drivers should only affect the effective
> > > interrupt affinities. This admittedly is more involved than it
> > appears
> > > at first because the interface interrupts would have to be balanced
> > > subject to multiple (potentially totally different) cpusets.
> > 
> > Exactly. Maybe it would work to align the driver with what igb does.
> 
> Currently, stmmac sets IRQ affinity and hints for all IRQ
> configurations. But on x86 systems with IOAPIC MSI-X vectors should be
> automatically balanced. If we remove the driver-based irq balancing
> then other architectures would not necessarily balance the interrupts
> anymore and would be impacted in terms of performance. Maybe driver-
> based irq balancing could be deactivated whenever the underlying system
> is capable of balancing them? That would of course only reduced the
> number of affected systems.
> 
> In general I lack information when drivers should (or are allowed to)
> balance interrupts on driver level and whether smp_affinity is allowed
> to be ignored and overwritten in that case. All documentation I have
> found so far remains rather unspecific.

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.

> Tobias

Sebastian