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

["Radim Krčmář" <rkrcmar@ventanamicro.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.