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. > 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? > 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? Mark. > > Any comment is appreciated. > > Thanks > > > [1] https://www.spinics.net/lists/arm-kernel/msg931861.html > > [2] https://www.spinics.net/lists/arm-kernel/msg932481.html > > > > > Thanks, > > > > tglx >
