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:

quoted

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.

quoted

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