Re: [External] [PATCH] RISC-V: store percpu offset in CSR_SCRATCH

From: "Radim Krčmář" <rkrcmar@ventanamicro.com>
To: "yunhui cui" <cuiyunhui@bytedance.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: Thu, 10 Jul 2025 08:35:15 +0200	[thread overview]
Message-ID: <DB8607ITP9UR.2LOW61O3OVJ2F@ventanamicro.com> (raw)
In-Reply-To: <CAEEQ3wnaL5X_jXEmbbWFp3jx1Aq=02Gf7kDNBS=wcPyfEq7yBw@mail.gmail.com>

2025-07-10T11:45:06+08:00, yunhui cui <cuiyunhui@bytedance.com>:
> On Wed, Jul 9, 2025 at 10:20 PM Radim Krčmář <rkrcmar@ventanamicro.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.