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: > > On Sun, Feb 22, 2026 at 11:06:11PM +0100, Thomas Gleixner wrote: > > > On Fri, Feb 20 2026 at 17:09, Jisheng Zhang wrote: > > > > 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. > > > 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. > > > 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. > > > 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? >
