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

["Christophe Leroy (CS GROUP)" <chleroy@kernel.org>]

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:
>> On Thu, Jul 30, 2026 at 4:53 PM Paul E. McKenney <paulmck@kernel.org> 
>> 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.

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

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