On Wed Nov 4, 2026 at 9:59 AM +08, Troy Mitchell wrote:
> On Tue Nov 3, 2026 at 11:52 PM +08, Anup Patel wrote:
> > On Tue, Nov 3, 2026 at 1:34 PM Troy Mitchell <troy.mitchell@linux.dev> wrote:
> > >
> > > Remote IMSIC state updates are deferred to a timer on the target CPU.
> > > If that CPU has stopped its local clockevent and is waiting for a
> > > broadcast interrupt, enabling the broadcast IRQ can depend on delivery
> > > of that same interrupt. This can stall timer delivery when the broadcast
> > > IRQ is unmasked or moved to another CPU, including during CPU hotplug.
> > >
> > > Queue hard IRQ work to synchronize remote state independently of timer
> > > delivery. Keep synchronous updates on the local CPU and the timer retry
> > > for an unfinished vector move. Hard IRQ work also avoids depending on a
> > > schedulable worker when PREEMPT_RT is enabled.
> >
> > Using timer retry for local CPU and IRQ work queue for remote CPUs looks
> > strange. Why not use IRQ work queue even for local CPU ??
> On the local CPU the sync runs synchronously, so there is nothing to
> queue. The timer only retries an unfinished move, and by then the new
> vector is already enabled, so it cannot stall on the broadcast IRQ.
> Requeueing IRQ work from its own handler would just keep self-IPIing
> until the old CPU catches up.
>
> I'll add more comments and modify the commit body.
That was not the whole story. The retry cannot stall, but it can be
late. The local CPU is usually the one entering idle and taking the
broadcast IRQ, and the timer it arms on itself there is not programmed
because its tick is already stopped. Nothing tells it when the old CPU
is done, so the move only completes on its next interrupt. On K3 with
deep idle I see move windows of up to 0.5s.

So you are right that the timer should go, just not by requeueing on
the local CPU. In v2 the old CPU will queue the IRQ work on the new CPU
once it has released the old vector, and the retry timer will be
removed. Move windows drop to about 100us. This will be a separate
patch on top of this one.

-- 
Troy Mitchell