[External] Re: [PATCH v9 1/3] riscv: implement this_cpu operations

[Jisheng Zhang]

On Mon, Nov 09, 2026 at 11:47:43AM +0800, yunhui cui wrote:
> Hi David,
> 
> On Mon, Nov 9, 2026 at 5:33 AM David Laight
> <david.laight.linux at gmail.com> wrote:
> >
> > On Sun,  8 Nov 2026 19:04:04 +0800
> > Yunhui Cui <cuiyunhui at bytedance.com> wrote:
> >
> > > RISC-V has no asm/percpu.h, so this_cpu_*() read-modify-write
> > > operations use generic implementations that disable local interrupts.
> > >
> > > Implement RISC-V-specific this_cpu operations with preemption disabled
> > > to keep accesses on the current CPU.
> >
> > Have you looked at some of the schemes (I think arm64 has the latest,
> > but also s390) that do most per-cpu ops without disabling preemption.
> > In particular they save the pre-emption check when pre-emption
> > is enabled.
> >
> > Basically the code tells the scheduler which register contains the
> > per-cpu data so that it can be 'magically' flipped during a context
> > switch.
> 
> Many thanks for pointing this out and suggesting this optimization. This
> is a very useful suggestion. In the common case no preemption or migration
> occurs, so the preemption bookkeeping and reschedule check are unnecessary
> overhead.
> 
> Implementing this scheme for RISC-V will require additional changes beyond
> the current series. If this series is otherwise acceptable, I would like
> to land the current this_cpu_* support first and then prepare a follow-up
> series using this approach.

Hi Yunhui and David,

During the merge window but before rc1, I implemented a riscv POC
following arm64's preemptible this cpu scheme. Each operation records
its per-cpu pointer, offset and address registers. Exception entry saves
and clears this state, and a noinstr c helper repairs the saved offset
and address registers on exception return after any migration.

However, my PoC is based on current percpu offset.

I planed to sent it out last Sunday, but then I found Yunhui sent
his percpu series(which is up to v9, I didn't know this before) on Sat.
So I hold on the sending.

Now would it make sense to rebase the PoC on Yunhui's series patch2 and
patch3, especially the percpu offset optimization? I can post an RFC
with this rebased implementation.

Thanks
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv