Re: [PATCH 3/3] arm64: use runtime constant to optimize handle_arch_irq access
From: Leo Yan
Date: Fri Feb 20 2026 - 07:34:30 EST
Hi Jisheng,
On Fri, Feb 20, 2026 at 05:09:22PM +0800, Jisheng Zhang wrote:
> Currently, on arm64 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.
>
> Tested on Quad CA55 platform, the perf sched benchmark is improved
> by ~6.5%
6.5% is a quite high margin, especially for only one pointer's change.
Maybe it is good to share more info for which compiler you are using,
how you tested and the detailed results.
I played a bit on my juno board on CA73 cores with the command:
perf bench sched all
Run 3 iterations, and measures three metrics (messaging/pipe/seccomp)
and results in seconds. Less is better.
+---------------------+--------+--------+--------+--------+
|Without change | run1 | run2 | run3 | avg |
+---------------------+--------+--------+--------+--------+
|messaging (sec) | 4.546 | 4.508 | 4.591 | 4.548 |
|pipe (sec) | 24.258 | 24.224 | 24.017 | 24.166 |
|seccomp-notify (sec) | 48.393 | 48.457 | 48.232 | 48.361 |
+---------------------+--------+--------+--------+--------+
+---------------------+--------+--------+--------+--------+--------+
|With change | run1 | run2 | run3 | avg | diff |
+---------------------+--------+--------+--------+--------+--------+
|messaging (sec) | 4.493 | 4.523 | 4.556 | 4.524 | +0.52% |
|pipe (sec) | 23.159 | 23.702 | 28.649 | 25.170 | -4.15% |
|seccomp-notify (sec) | 46.848 | 46.938 | 46.973 | 46.920 | +2.98% |
+---------------------+--------+--------+--------+--------+--------+
With this patch, the messaging test shows a minor improvement (0.52%).
The pipe test performs worse (-4.15%) after applying the patch. However,
one positive signal is that the minimum latency is 23.159, which is
lower than without the change (24.017).
For seccomp, the results indicate a benefit (2.98%) from the change.
Hope this is helpful for maintainers to judge the change.
I'd leave maintainers to review the code.
Thanks,
Leo