linux-kernel - Re: [External] [PATCH] RISC-V: store percpu offset in CSR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DB7L9ZHZI3AI.36SXWX2SO9OS7@ventanamicro.com>
Date: Wed, 09 Jul 2025 16:20:38 +0200
From: Radim Krčmář <rkrcmar@...tanamicro.com>
To: "yunhui cui" <cuiyunhui@...edance.com>
Cc: <masahiroy@...nel.org>, <nathan@...nel.org>, <nicolas.schier@...ux.dev>,
 <dennis@...nel.org>, <tj@...nel.org>, <cl@...two.org>,
 <paul.walmsley@...ive.com>, <palmer@...belt.com>, <aou@...s.berkeley.edu>,
 <alex@...ti.fr>, <andybnac@...il.com>, <bjorn@...osinc.com>,
 <cyrilbur@...storrent.com>, <rostedt@...dmis.org>, <puranjay@...nel.org>,
 <ben.dooks@...ethink.co.uk>, <zhangchunyan@...as.ac.cn>,
 <ruanjinjie@...wei.com>, <jszhang@...nel.org>, <charlie@...osinc.com>,
 <cleger@...osinc.com>, <antonb@...storrent.com>, <ajones@...tanamicro.com>,
 <debug@...osinc.com>, <haibo1.xu@...el.com>, <samuel.holland@...ive.com>,
 <linux-kbuild@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <linux-mm@...ck.org>, <linux-riscv@...ts.infradead.org>, "linux-riscv"
 <linux-riscv-bounces@...ts.infradead.org>, <wangziang.ok@...edance.com>
Subject: Re: [External] [PATCH] RISC-V: store percpu offset in CSR_SCRATCH

2025-07-09T19:42:26+08:00, yunhui cui <cuiyunhui@...edance.com>:
> 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

Great results.

> 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.

I assume the same.

> The following is the patch without percpu optimization, which only
> tests the overhead of separating exceptions into kernel and user
> modes.

Is the overhead above with this patch?  And when we then use the
CSR_SCRATCH for percpu, does it degrade even further?

Thanks.