public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jisheng Zhang <jszhang@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Thomas Gleixner <tglx@kernel.org>, Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>, Guo Ren <guoren@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org, linux-csky@vger.kernel.org
Subject: Re: [PATCH 3/3] arm64: use runtime constant to optimize handle_arch_irq access
Date: Mon, 23 Feb 2026 20:58:52 +0800	[thread overview]
Message-ID: <aZxPDBLpTm4yHQWY@xhacker> (raw)
In-Reply-To: <aZxOe_1XGX_gGOoK@J2N7QTR9R3>

On Mon, Feb 23, 2026 at 12:56:27PM +0000, Mark Rutland wrote:
> 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%
> 
> That is a surprisingly large impact. :/
> 
> Does this meaningfully actually affect any real workload?

all irqs' processing is improved to this extent. The perf sched
bench(an existing and good benchmark to measure IPI) is used to
show how much will be the improvement.

> 
> > Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
> > ---
> >  arch/arm64/kernel/entry-common.c | 4 +++-
> >  arch/arm64/kernel/irq.c          | 9 ++++++---
> >  2 files changed, 9 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> > index 3625797e9ee8..46a4c012e15f 100644
> > --- a/arch/arm64/kernel/entry-common.c
> > +++ b/arch/arm64/kernel/entry-common.c
> > @@ -25,6 +25,7 @@
> >  #include <asm/kprobes.h>
> >  #include <asm/mmu.h>
> >  #include <asm/processor.h>
> > +#include <asm/runtime-const.h>
> >  #include <asm/sdei.h>
> >  #include <asm/stacktrace.h>
> >  #include <asm/sysreg.h>
> > @@ -139,7 +140,8 @@ static void do_interrupt_handler(struct pt_regs *regs,
> >  	set_irq_regs(old_regs);
> >  }
> >  
> > -extern void (*handle_arch_irq)(struct pt_regs *);
> > +extern void (*_handle_arch_irq)(struct pt_regs *);
> > +#define handle_arch_irq runtime_const_ptr(_handle_arch_irq)
> >  extern void (*handle_arch_fiq)(struct pt_regs *);
> 
> We should treat handle_arch_irq and handle_arch_fiq the same way. Either
> both get this, or neither do.
> 
> >  static void noinstr __panic_unhandled(struct pt_regs *regs, const char *vector,
> > diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
> > index 15dedb385b9e..30629c183606 100644
> > --- a/arch/arm64/kernel/irq.c
> > +++ b/arch/arm64/kernel/irq.c
> > @@ -23,6 +23,7 @@
> >  #include <asm/daifflags.h>
> >  #include <asm/exception.h>
> >  #include <asm/numa.h>
> > +#include <asm/runtime-const.h>
> >  #include <asm/softirq_stack.h>
> >  #include <asm/stacktrace.h>
> >  #include <asm/vmap_stack.h>
> > @@ -84,15 +85,17 @@ static void default_handle_fiq(struct pt_regs *regs)
> >  	panic("FIQ taken without a root FIQ handler\n");
> >  }
> >  
> > -void (*handle_arch_irq)(struct pt_regs *) __ro_after_init = default_handle_irq;
> > +void (*_handle_arch_irq)(struct pt_regs *) __ro_after_init = default_handle_irq;
> > +#define handle_arch_irq runtime_const_ptr(_handle_arch_irq)
> 
> This breaks the default case, since handle_arch_irq is initialized to a
> bunch of garbage hex bytes (0x0123456789abcdef).
> 
> That means that if set_handle_irq() isn't called, an IRQ will result in
> a call to that bogus address rather than default_handle_irq(), which'll
> be more difficult to debug.

Oops, you're right. If runtime constants is chosen, I will address this
comment. While Thomas suggested static call instead. I found you
concerned with the arm64's static call implementation 5 years ago, I
mentioned this in another email a few seconds ago. Could you plz comment
the thread?

> 
> Mark.
> 
> >  void (*handle_arch_fiq)(struct pt_regs *) __ro_after_init = default_handle_fiq;
> >  
> >  int __init set_handle_irq(void (*handle_irq)(struct pt_regs *))
> >  {
> > -	if (handle_arch_irq != default_handle_irq)
> > +	if (_handle_arch_irq != default_handle_irq)
> >  		return -EBUSY;
> >  
> > -	handle_arch_irq = handle_irq;
> > +	_handle_arch_irq = handle_irq;
> > +	runtime_const_init(ptr, _handle_arch_irq);
> >  	pr_info("Root IRQ handler: %ps\n", handle_irq);
> >  	return 0;
> >  }
> > -- 
> > 2.51.0
> > 
> > 

      reply	other threads:[~2026-02-23 13:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-20  9:09 [PATCH 0/3] use runtime constant to optimize handle_arch_irq access Jisheng Zhang
2026-02-20  9:09 ` [PATCH 1/3] vmlinux.lds.h: add _handle_arch_irq RUNTIME_CONST section Jisheng Zhang
2026-02-24  2:01   ` Guo Ren
2026-02-20  9:09 ` [PATCH 2/3] genirq: use runtime constant to optimize handle_arch_irq access Jisheng Zhang
2026-02-22 22:06   ` Thomas Gleixner
2026-02-23 12:41     ` Jisheng Zhang
2026-02-23 13:11       ` Mark Rutland
2026-02-23 13:22         ` Jisheng Zhang
2026-02-23 13:55           ` Mark Rutland
2026-02-24  1:40   ` Guo Ren
2026-02-24  1:59     ` Guo Ren
2026-02-20  9:09 ` [PATCH 3/3] arm64: " Jisheng Zhang
2026-02-20 12:34   ` Leo Yan
2026-02-20 13:16     ` Jisheng Zhang
2026-02-20 13:34       ` Jisheng Zhang
2026-02-20 16:47         ` Leo Yan
2026-02-21  0:14           ` Jisheng Zhang
2026-02-23  9:15             ` Leo Yan
2026-02-25 14:40               ` Jisheng Zhang
2026-02-23 12:56   ` Mark Rutland
2026-02-23 12:58     ` Jisheng Zhang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZxPDBLpTm4yHQWY@xhacker \
    --to=jszhang@kernel.org \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=guoren@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-csky@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=tglx@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox