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.
