Re: [PATCH v4 1/1] powerpc: enable dynamic preemption

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