From: yunhui cui <cuiyunhui@bytedance.com>
To: "Radim Krčmář" <rkrcmar@ventanamicro.com>
Cc: masahiroy@kernel.org, nathan@kernel.org,
nicolas.schier@linux.dev, dennis@kernel.org, tj@kernel.org,
cl@gentwo.org, paul.walmsley@sifive.com, palmer@dabbelt.com,
aou@eecs.berkeley.edu, alex@ghiti.fr, andybnac@gmail.com,
bjorn@rivosinc.com, cyrilbur@tenstorrent.com,
rostedt@goodmis.org, puranjay@kernel.org,
ben.dooks@codethink.co.uk, zhangchunyan@iscas.ac.cn,
ruanjinjie@huawei.com, jszhang@kernel.org, charlie@rivosinc.com,
cleger@rivosinc.com, antonb@tenstorrent.com,
ajones@ventanamicro.com, debug@rivosinc.com,
haibo1.xu@intel.com, samuel.holland@sifive.com,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-riscv@lists.infradead.org,
linux-riscv <linux-riscv-bounces@lists.infradead.org>,
wangziang.ok@bytedance.com
Subject: Re: [External] [PATCH] RISC-V: store percpu offset in CSR_SCRATCH
Date: Wed, 9 Jul 2025 19:42:26 +0800 [thread overview]
Message-ID: <CAEEQ3wkoy3Jr0vZk=X4U56KYPq3=5t7Wr4RE6uNby3MS5qzh-g@mail.gmail.com> (raw)
In-Reply-To: <DB6MLPA3BJ75.2U5FP5JSJD2LO@ventanamicro.com>
Hi Radim,
On Tue, Jul 8, 2025 at 7:10 PM Radim Krčmář <rkrcmar@ventanamicro.com> wrote:
>
> 2025-07-08T18:07:27+08:00, yunhui cui <cuiyunhui@bytedance.com>:
> > This patch cleverly differentiates whether an exception originates
> > from user mode or kernel mode. However, there's still an issue with
> > using CSR_SCRATCH: each time handle_exception() is called, the
> > following instructions must be executed:
> >
> > REG_L s0, TASK_TI_CPU(tp)
> > slli s0, s0, 3
> > la s1, __per_cpu_offset
> > add s1, s1, s0
> > REG_L s1, 0(s1)
> > csrw CSR_SCRATCH, s1
>
> We can minimize the cost at exception entry by storing the precomputed
> offset in thread_info, which bloats the struct, and also incurs update
> cost on cpu migration, but should still be a net performance gain.
>
> The minimal code at exception entry would be:
>
> REG_L s0, TASK_TI_PERCPU_OFFSET(tp)
> csrw CSR_SCRATCH, s0
>
> > Should we consider adding a dedicated CSR (e.g., CSR_SCRATCH2) to
> > store the percpu offset instead?
> > See: https://lists.riscv.org/g/tech-privileged/topic/113437553#msg2506
>
> It would be nice to gather more data on the CSR_SCRATCH approach.
> Basically, the overhead of "REG_L s0, TASK_TI_PERCPU_OFFSET(tp)".
> (Or the longer sequence if we think it is worth it.)
>
> Can you benchmark the patch after reverting percpu.h, so we include the
> overhead of switching CSR_SCRATCH, but without any benefits provided by
> the per-cpu offset?
> The baseline would be the patch with reverted percpu.h, and reverted the
> sequence that sets the CSR_SCRATCH in handle_exception, so we roughly
> estimate the benefit of adding CSR_SCRATCH2.
>
> The CSR_SCRATCH2 does add overhead to hardware, and to domain context
> switches, and we also have to do something else for a few years anyway,
> because it's not even ratified... It's possible we might not benefit
> enough from CSR_SCRATCH2 to make a good case for it.
>
> Thanks.
Bench platform: Spacemit(R) X60
No changes:
6.77, 6.791, 6.792, 6.826, 6.784, 6.839, 6.776, 6.733, 6.795, 6.763
Geometric mean: 6.786839305
Reusing the current scratch:
7.085, 7.09, 7.021, 7.089, 7.068, 7.034, 7.06, 7.062, 7.065, 7.051
Geometric mean: 7.062466876
A degradation of approximately 4.06% is observed. The possible cause
of the degradation is that the CSR_TVEC register is set every time a
kernel/user exception occurs.
The following is the patch without percpu optimization, which only
tests the overhead of separating exceptions into kernel and user
modes.
---
arch/riscv/kernel/entry.S | 39 ++++++++++++++++++++++-----------------
arch/riscv/kernel/head.S | 7 +------
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index 9d1a305d5508..cc2fd4cd54a0 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -19,17 +19,8 @@
.section .irqentry.text, "ax"
-SYM_CODE_START(handle_exception)
- /*
- * If coming from userspace, preserve the user thread pointer and load
- * the kernel thread pointer. If we came from the kernel, the scratch
- * register will contain 0, and we should continue on the current TP.
- */
- csrrw tp, CSR_SCRATCH, tp
- bnez tp, .Lsave_context
-
-.Lrestore_kernel_tpsp:
- csrr tp, CSR_SCRATCH
+SYM_CODE_START(handle_kernel_exception)
+ csrw CSR_SCRATCH, tp
REG_S sp, TASK_TI_KERNEL_SP(tp)
#ifdef CONFIG_VMAP_STACK
@@ -40,7 +31,20 @@ SYM_CODE_START(handle_exception)
REG_L sp, TASK_TI_KERNEL_SP(tp)
#endif
-.Lsave_context:
+ j handle_exception
+SYM_CODE_END(handle_kernel_exception)
+
+SYM_CODE_START(handle_user_exception)
+ /*
+ * If coming from userspace, preserve the user thread pointer and load
+ * the kernel thread pointer.
+ */
+ csrrw tp, CSR_SCRATCH, tp
+ j handle_exception
+
+SYM_CODE_END(handle_user_exception)
+
+SYM_CODE_START_NOALIGN(handle_exception)
REG_S sp, TASK_TI_USER_SP(tp)
REG_L sp, TASK_TI_KERNEL_SP(tp)
addi sp, sp, -(PT_SIZE_ON_STACK)
@@ -71,11 +75,8 @@ SYM_CODE_START(handle_exception)
REG_S s4, PT_CAUSE(sp)
REG_S s5, PT_TP(sp)
- /*
- * Set the scratch register to 0, so that if a recursive exception
- * occurs, the exception vector knows it came from the kernel
- */
- csrw CSR_SCRATCH, x0
+ la s1, handle_kernel_exception
+ csrw CSR_TVEC, s1
/* Load the global pointer */
load_global_pointer
@@ -141,6 +142,10 @@ SYM_CODE_START_NOALIGN(ret_from_exception)
* structures again.
*/
csrw CSR_SCRATCH, tp
+
+ la a0, handle_user_exception
+ csrw CSR_TVEC, a0
+
1:
#ifdef CONFIG_RISCV_ISA_V_PREEMPTIVE
move a0, sp
diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
index a2e2f0dd3899..992acec3bc87 100644
--- a/arch/riscv/kernel/head.S
+++ b/arch/riscv/kernel/head.S
@@ -172,14 +172,9 @@ secondary_start_sbi:
.align 2
.Lsetup_trap_vector:
/* Set trap vector to exception handler */
- la a0, handle_exception
+ la a0, handle_kernel_exception
csrw CSR_TVEC, a0
- /*
- * Set sup0 scratch register to 0, indicating to exception vector that
- * we are presently executing in kernel.
- */
- csrw CSR_SCRATCH, zero
ret
.align 2
--
2.43.0
Thanks,
Yunhui
next prev parent reply other threads:[~2025-07-09 11:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-04 8:45 [PATCH RFC] RISC-V: Fix a register to store the percpu offset Yunhui Cui
2025-07-07 7:55 ` Clément Léger
2025-07-07 12:50 ` [PATCH] RISC-V: store percpu offset in CSR_SCRATCH Radim Krčmář
2025-07-08 10:07 ` [External] " yunhui cui
2025-07-08 11:10 ` Radim Krčmář
2025-07-09 11:42 ` yunhui cui [this message]
2025-07-09 14:20 ` Radim Krčmář
2025-07-10 3:45 ` yunhui cui
2025-07-10 6:35 ` Radim Krčmář
2025-07-10 11:47 ` yunhui cui
2025-07-10 16:40 ` [PATCH] RISC-V: store precomputed percpu_offset in the task struct Radim Krčmář
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='CAEEQ3wkoy3Jr0vZk=X4U56KYPq3=5t7Wr4RE6uNby3MS5qzh-g@mail.gmail.com' \
--to=cuiyunhui@bytedance.com \
--cc=ajones@ventanamicro.com \
--cc=alex@ghiti.fr \
--cc=andybnac@gmail.com \
--cc=antonb@tenstorrent.com \
--cc=aou@eecs.berkeley.edu \
--cc=ben.dooks@codethink.co.uk \
--cc=bjorn@rivosinc.com \
--cc=charlie@rivosinc.com \
--cc=cl@gentwo.org \
--cc=cleger@rivosinc.com \
--cc=cyrilbur@tenstorrent.com \
--cc=debug@rivosinc.com \
--cc=dennis@kernel.org \
--cc=haibo1.xu@intel.com \
--cc=jszhang@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv-bounces@lists.infradead.org \
--cc=linux-riscv@lists.infradead.org \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=nicolas.schier@linux.dev \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=puranjay@kernel.org \
--cc=rkrcmar@ventanamicro.com \
--cc=rostedt@goodmis.org \
--cc=ruanjinjie@huawei.com \
--cc=samuel.holland@sifive.com \
--cc=tj@kernel.org \
--cc=wangziang.ok@bytedance.com \
--cc=zhangchunyan@iscas.ac.cn \
/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