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

Le 30/07/2026 à 19:10, Shrikanth Hegde a écrit :

Hi Jirka, Paul,


+cc will

On 7/30/26 8:38 PM, Jirka Hladky wrote:

quoted

On Thu, Jul 30, 2026 at 4:53 PM Paul E. McKenney [off-list ref] 
wrote:

quoted

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.

Might be a stupid question, but what is your .config ?
Are you sure it doesn't contain CONFIG_DEBUG_PREEMPT ?

quoted

quoted

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)

quoted

quoted

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