Re: Control of IRQ Affinities from Userspace

[Frederic Weisbecker <frederic@kernel.org>]

Le Tue, Nov 25, 2025 at 12:32:39PM +0100, Florian Bezdeka a écrit :
> On Mon, 2025-11-24 at 10:59 +0100, bigeasy@linutronix.de wrote:
> > 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.
> 
> In case that was still unclear: We're using the dynamic system
> configuration features provided by cpusets/cgrups. No isolcpus= on the
> kernel cmdline anymore. With that all applications are build around
> cgroups. There is some userspace tooling around that takes care of
> proper system configuration / RT isolation.
> 
> > 
> > …
> > > > > 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.
> 
> 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.
> 
> The point here is, that drivers (like the stmmac, storage, ...) simply
> ignore everything that was configured by userspace. As soon as one of
> the dynamic events (link up/down, bpf loading) occurs they destroy the
> current RT aware system configuration.
> 
> I was not successful in finding an API that would allow the driver(s) to
> do better. The default affinity (/proc/irq/default_smp_affinity) - as an
> example - is not visible from outside the IRQ core.
> 
> The managed IRQ infrastructure that you mentioned seems coupled with the
> interfaces behind CONFIG_CPU_ISOLATION which seems to be "static", so
> configured at boot time. Is that understanding correct? That would not
> be flexible enough as we don't know the system configuration at boot
> time.
> 
> As we now have Frederic with us: Frederic, are there any plans to extend
> the housekeeping API to deal with cpuset creation? Not sure if that
> would be possible as it's hard to say if the newly created cpuset is
> targeting isolation or housekeeping...

I'm not sure what you mean by that. But HK_TYPE_DOMAIN will soon include
both isolcpus and cpuset isolated partitions. And the next step is to be
able to create nohz_full/isolated cpuset partitions.

Thanks.

-- 
Frederic Weisbecker
SUSE Labs