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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <DB8607ITP9UR.2LOW61O3OVJ2F@ventanamicro.com>
Date: Thu, 10 Jul 2025 08:35:15 +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-10T11:45:06+08:00, yunhui cui <cuiyunhui@...edance.com>:
> On Wed, Jul 9, 2025 at 10:20 PM Radim Krčmář <rkrcmar@...tanamicro.com> wrote:
>> Is the overhead above with this patch?  And when we then use the
>> CSR_SCRATCH for percpu, does it degrade even further?
>
> We can see that the percpu optimization is around 2.5% through the
> method of fixing registers, and we can consider that the percpu
> optimization can bring a 2.5% gain. Is there no need to add the percpu
> optimization logic on the basis of the scratch patch for testing?
>
> Reference: https://lists.riscv.org/g/tech-privileged/message/2485

That is when the value is in a GPR, though, and we don't know the
performance of a CSR_SCRATCH access.
We can hope that it's not much worse than a GPR, but an implementation
might choose to be very slow with CSR_SCRATCH.

I have in mind another method where we can use the current CSR_SCRATCH
without changing CSR_TVAL, but I don't really want to spend time on it
if reading the CSR doesn't give any benefit.

It would be to store the percpu offset in CSR_SCRATCH permanently, do
the early exception register shuffling with a percpu area storage, and
load the thread pointer from there as well.
That method would also eliminate writing CSR_SCRATCH on every exception
entry+exit, so maybe it makes sense to try it even if CSRs are slow...

Thanks.