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

[Jisheng Zhang]

On Mon, Nov 09, 2026 at 01:49:05PM +0800, yunhui cui wrote:
> Hi Jisheng,
> 
> On Mon, Nov 9, 2026 at 12:57 PM Jisheng Zhang <jszhang at kernel.org> wrote:
> >
> > 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.
> >
> 
> Given the substantial effort already invested in bringing this series
> to v9, my original plan was to land the current implementation first
> and add the preemptible scheme as a follow-up.
> 
> However, if the consensus is to move directly to the preemptible scheme,
> I will implement this scheme in the next revision, building on the
> cached percpu offset introduced in patch 2.
> 
yes, I suggest go with the preemptible design from the beginning. It
avoids introducing preemption-disabled wrappers that would later be
removed. But your preemption-disabled version isn't dropped, it can
be used for performance comparison. We can do similar benchmark
as arm64 does:
https://lore.kernel.org/linux-arm-kernel/28978498-348e-4cfd-af72-1146a106e96b@arm.com/