On Mon, Feb 23, 2026 at 01:11:46PM +0000, Mark Rutland wrote:

On Mon, Feb 23, 2026 at 08:41:55PM +0800, Jisheng Zhang wrote:

quoted

On Sun, Feb 22, 2026 at 11:06:11PM +0100, Thomas Gleixner wrote:

quoted

On Fri, Feb 20 2026 at 17:09, Jisheng Zhang wrote:

quoted

Currently, on GENERIC_IRQ_MULTI_HANDLER platforms, the handle_arch_irq
is a pointer which is set during booting, and every irq processing needs
to access it, so it sits in hot code path. We can use the
runtime constant mechanism which was introduced by Linus to speed up
its accessing.

The proper solution is to use a static call and update it in
set_handle_irq().  That removes the complete indirect call issue from
the hot path.

+ Ard, Mark,

Good idea. The remaining problem is no static call support for current
GENERIC_IRQ_MULTI_HANDLER (or similar, arm64 e.g) platforms.

There are various reasons for not supporting static calls, and in
general we end up having to have a fall-back path that's *more*
expensive than just loading the pointer.

indeed, if arch doesn't support static call, the fall-back addes one
more loading overhead.

quoted

For arm64, Ard tried to add the static call support[1] in 2021, but
Mark concerned "compiler could easily violate our expectations in
future"[2],

To be clear, that's ONE specific concern, not the ONLY reason.

quoted

and asked for static calls "critical rather than a nice-to-have"
usage.

Hi Ard, Mark,

Could this irq performance improvement be used as a "critical" usage for
arm64 static call? Per my test, about 6.5% improvement was seen on quad CA55.

As per my other mail, does this meaningfully affect a real workload?

This improves generic irq processcing, I think all real workload is affected.

quoted

Another alternative: disable static call if CFI is enabled, and give
the platform/SoC users chance to enable static call to benefit from
it.

Who is this actually going to matter to?