Re: [PATCH 2/3] genirq: use runtime constant to optimize handle_arch_irq access

[Mark Rutland <mark.rutland@arm.com>]

On Mon, Feb 23, 2026 at 09:22:44PM +0800, Jisheng Zhang wrote:
> On Mon, Feb 23, 2026 at 01:11:46PM +0000, Mark Rutland wrote:
> > 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.

I think you've misunderstood my point.

I'm saying that *even if* arm64 supported static calls, we'd have to
have dynamic fallback paths that are more expensive. For example, where
branch range limitations force indirection via an out-of-line stub,
adding an extra BL+RET pair. Note that was the case in the patches you
linked from Ard.

[...]

> > > 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.

I asked about meaningful impact. For a real workload, does this show up
at all, or does this fall within the noise?

At present, I don't think your singular microbenchmark result changes
our previous decisions regarding static calls. For various reasons, on
arm64 static calls are nowhere near as significant an optimization (and
can be worse).

I'd be happy to use a runtime constant (modulo my concerns about the
initial value) given that the we already have the infrastructure and the
maintenanace impact is minimal.

Mark.