IRQ thread timeouts and affinity

[Marc Zyngier]

On Tue, 14 Oct 2025 12:08:22 +0100,
Thierry Reding <thierry.reding at gmail.com> wrote:
>

[...]

> > The interrupt count for CPUs 2-7 no longer increments after taking CPU 1
> > offline. Interestingly, bringing CPU 1 back online doesn't have an
> > impact, so it doesn't go back to enabling 1:N mode.
> 
> Looks like that is because gic_set_affinity() gets called with the new
> CPU mask when the CPU goes offline, but it's *not* called when the CPU
> comes back online.

Indeed, because there is no need to change the affinity as far as the
kernel is concerned -- the interrupt is on an online CPU and all is
well.

I think that's the point where a per-interrupt flag (let's call it
IRQ_BCAST for the sake of argument) is required to decide what to
do. Ideally, IRQ_BCAST would replace any notion of affinity, and you'd
get the scatter-gun behaviour all the time. Which means no adjustment
to the affinity on a CPU going offline (everything still works).

But that's assumes a bunch of other things:

- when going offline, at least DPG1NS gets set to make sure this CPU
  is not a target anymore if not going completely dead (still running
  secure code, for example). The kernel could do it, but...

- when going idle, should this CPU still be a target of 1:N
  interrupts? That's a firmware decision what could severely impact
  power on battery-bound machines if not carefully managed...

- and should a CPU wake up from such an interrupt? Again, that's a
  firmware decision, and I don't know how existing implementation deal
  with that stuff.

Someone needs to investigate these things, and work out all of the
above. That will give us a set of conditions under which we could do
something.

	M.

-- 
Jazz isn't dead. It just smells funny.