Re: [PATCH RFC 2/3] genirq: Honor existing IRQ affinities when setting affinity hints

[ Might be a resend, got some HTML warnings for unknown reasons...]

On Fri, 2026-08-21 at 12:53 +0200, Sebastian Andrzej Siewior wrote:
> On 2026-08-21 12:38:52 [+0200], Jan Kiszka wrote:
> > Fully agree: drivers should not set affinities. They should just express
> > desires or additional constraints. The ultimately resulting affinity for
> > an IRQ should be the result of the various constraints that kernel and
> > userland may express via NUMA placements, isolcpus, some dynamic
> > isolation/grouping constraints, or you-name-it.
> 
> You might want to look at irq_create_affinity_masks()/
> group_cpus_evenly() which attempts to spread irqs evenly across CPUs/
> NUMA nodes. This is used by storage is considered a bit by the
> isolcpus=managed_irq option.

I'm aware of those functions but faced the following shortcomings
regarding timing:

1) irq_create_affinity_masks() is called on probe() time, which normally
is "boot time". Userspace is not up and running yet, so the
default_smp_affinity was not properly set up.

2) You can not overwrite the affinities set on probe() time until
request_irq() populates the affinities to /proc - and with that the
interface itself - at open()/"interface up for the first time" time.

If the default_smp_affinity changes until your interface comes up for
the first time, it might violate the current settings already. No chance
for a user to correct the current (device) settings.

> 
> > I think we need a big picture how things should eventually look like and
> > then develop a strategy how to step-wise convert existing code.
> > 
> > 

I just received the confirmation email that my abstract, which I
submitted to the Linux Plumbers Conference (Scheduler and Real-Time
micro-conference), has been accepted. There will be a session called
"PREEMPT_RT: How a simple interface up event might break your realtime".

Seems we have the chance to discuss this topic in person.

Florian