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

Shrikanth Hegde <[email protected]> Thu, 30 Jul 2026 22:40:38 +0530
Newsgroups org.ozlabs.lists.linuxppc-dev,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
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)



>>
>> 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