On Thu, Jul 30, 2026 at 10:40:38PM +0530, Shrikanth Hegde wrote:
> Hi Jirka, Paul,
>
>
> +cc will
>
> On 7/30/26 8:38 PM, Jirka Hladky wrote:
> > On Thu, Jul 30, 2026 at 4:53 PM Paul E. McKenney <[email protected]> wrote:
> > > But is this really a fundamental RISC cost? For example, does arm64
> > > see the same performance issues?
> >
> > We tested arm64 (Ampere Altra Max) with the same controlled
> > experiment -- two 6.18 kernels, both voluntary, differing only in
> > PREEMPT_DYNAMIC:
> >
> > Arch PREEMPT_DYNAMIC kill bogo-ops/sec Delta
> > ------- --------------- ----------------- -----
> > ppc64le off 108,836
> > ppc64le on 68,197 -37.3%
> > aarch64 off 5,538
> > aarch64 on 5,082 -8.2%
> >
> > arm64 sees -8.2% vs ppc64le's -37.3%. So arm64 is affected but
> > much less severely.
>
> Ouch!. But that's good to know.
>
> >
> > > In particular, I can see why the preempt_count() operations need to be
> > > interrupt-safe, but I don't see why you would need barriers. And
> > > doesn't powerpc still use software interrupt disabling? If so, why
> > > not use that to simply software-disable interrupts around the
> > > preempt_count() operations?
>
> Barrier are in core implementation, not in arch specific.
>
> #ifdef CONFIG_PREEMPT_COUNT
> #define preempt_disable() \
> do { \
> preempt_count_inc(); \
> barrier(); \
> } while (0)
>
>
> #ifdef CONFIG_PREEMPTION
> #define preempt_enable() \
> do { \
> barrier(); \
> if (unlikely(preempt_count_dec_and_test())) \
> __preempt_schedule(); \
> } while (0)
But barrier() is just "__asm__ __volatile__("": : :"memory")", which
does not emit any instructions. Or is this doing more machine-register
flushing/restoring than one might expect?
> > > What am I missing here?
> >
> > That's a good question -- I don't know enough about the powerpc
> > preempt_count implementation to answer this. Shrikanth, could you
> > comment on whether removing the barriers or using software interrupt
> > disabling around preempt_count is feasible?
> >
> > Thank you
> > Jirka
> >
>
> PowerPC currently uses asm-generic implementation which is probably
> sub-optimal
> w.r.t to check of need_resched.
>
> When i see ARM's implementation, i see there is trick of splitting it into
> two.
>
> union {
> u64 preempt_count; /* 0 => preemptible, <0 =>
> bug */
> struct {
> #ifdef CONFIG_CPU_BIG_ENDIAN
> u32 need_resched;
> u32 count;
> #else
> u32 count;
> u32 need_resched;
> #endif
> } preempt;
> };
>
>
> Seeing Will's changelog is on similar direction.
>
> 396244692232 arm64: preempt: Provide our own implementation of asm/preempt.h
> "The asm-generic/preempt.h implementation doesn't make use of the
> PREEMPT_NEED_RESCHED flag, since this can interact badly with load/store
> architectures which rely on the preempt_count word being unchanged across
> an interrupt.
>
> However, since we're a 64-bit architecture and the preempt count is
> only 32 bits wide, we can simply pack it next to the resched flag and
> load the whole thing in one go, so that a dec-and-test operation doesn't
> need to load twice. "
>
> I am speculating this might help solve for ppc64 too. But i don't have a
> system
> to try this right now, will get back once i do
Looking forward to seeing what you come up with!
Thanx, Paul
