From: "Troy Mitchell" <troy.mitchell@linux.dev>
To: "Anup Patel" <anup@brainfault.org>
Cc: "Troy Mitchell" <troy.mitchell@linux.dev>,
"Thomas Gleixner" <tglx@kernel.org>,
"Radu Rendec" <radu@rendec.net>, "Paul Walmsley" <pjw@kernel.org>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Alexandre Ghiti" <alex@ghiti.fr>,
"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
"Clark Williams" <clrkwllms@kernel.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Björn Töpel" <bjorn@kernel.org>,
"Anup Patel" <apatel@ventanamicro.com>,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH] irqchip/riscv-imsic: Synchronize remote state with IRQ work
Date: Tue, 10 Nov 2026 07:27:07 +0000 [thread overview]
Message-ID: <DMRCPRZVNPGZ.3HTEULWLQ76YL@linux.dev> (raw)
In-Reply-To: <DMM1ZNXOFC8Q.HXUWNWMD6LKE@linux.dev>
[-- Attachment #1: Type: text/plain, Size: 2137 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
next prev parent reply other threads:[~2026-11-10 7:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 8:04 Troy Mitchell
2026-11-03 8:59 ` Sebastian Andrzej Siewior
2026-11-03 15:52 ` Anup Patel
2026-11-04 1:59 ` Troy Mitchell
2026-11-10 7:27 ` Troy Mitchell [this message]
2026-11-10 7:39 ` Anup Patel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DMRCPRZVNPGZ.3HTEULWLQ76YL@linux.dev \
--to=troy.mitchell@linux.dev \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=bigeasy@linutronix.de \
--cc=bjorn@kernel.org \
--cc=clrkwllms@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=radu@rendec.net \
--cc=rostedt@goodmis.org \
--cc=tglx@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®