LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Shrikanth Hegde <sshegde@linux.ibm.com>
To: Jirka Hladky <jhladky@redhat.com>, paulmck@kernel.org
Cc: maddy@linux.ibm.com, linuxppc-dev@lists.ozlabs.org,
	christophe.leroy@csgroup.eu, mpe@ellerman.id.au,
	npiggin@gmail.com, bigeasy@linutronix.de, will@kernel.org,
	linux-kernel@vger.kernel.org, Will Deacon <will@kernel.org>
Subject: Re: [PATCH v4 1/1] powerpc: enable dynamic preemption
Date: Thu, 30 Jul 2026 22:40:38 +0530	[thread overview]
Message-ID: <57d9de4a-65aa-44cf-9024-de4e5bdd1971@linux.ibm.com> (raw)
In-Reply-To: <CAE4VaGDJxcu_zgDyrSW=j9WzLEpNsQ9A9Rza-F5PLZq03kJYew@mail.gmail.com>

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.

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


  parent reply	other threads:[~2026-07-30 17:11 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-10 18:43 [PATCH v4 0/1] powerpc: Enable dynamic preemption Shrikanth Hegde
2025-02-10 18:43 ` [PATCH v4 1/1] powerpc: enable " Shrikanth Hegde
2026-07-26 18:33   ` Jirka Hladky
2026-07-27  4:18     ` Shrikanth Hegde
2026-07-27 10:13       ` Jirka Hladky
2026-07-27 10:28         ` Shrikanth Hegde
2026-07-27 10:35           ` Christophe Leroy (CS GROUP)
2026-07-27 16:12             ` Paul E. McKenney
2026-07-27 10:59           ` Jirka Hladky
2026-07-27 11:03             ` Shrikanth Hegde
2026-07-27 12:34         ` Shrikanth Hegde
2026-07-27 16:07       ` Paul E. McKenney
2026-07-27 16:50         ` Jirka Hladky
2026-07-27 17:10           ` Shrikanth Hegde
2026-07-27 18:29             ` Christophe Leroy (CS GROUP)
2026-07-28  5:27               ` Shrikanth Hegde
2026-07-28 16:21                 ` Paul E. McKenney
2026-07-28 16:30                   ` Paul E. McKenney
2026-07-30 13:01                   ` Shrikanth Hegde
2026-07-30 14:51                     ` Paul E. McKenney
2026-07-28  0:26             ` Jirka Hladky
2026-07-28  5:11               ` Shrikanth Hegde
2026-07-28 14:19                 ` Jirka Hladky
2026-07-30  6:44                   ` Shrikanth Hegde
2026-07-30 12:08                     ` Jirka Hladky
2026-07-30 14:47                       ` Paul E. McKenney
2026-07-30 15:08                         ` Jirka Hladky
2026-07-30 16:26                           ` Paul E. McKenney
2026-07-30 17:10                           ` Shrikanth Hegde [this message]
2026-07-30 17:26                             ` Paul E. McKenney
2026-07-30 18:40                               ` Segher Boessenkool
2026-07-31  4:59                                 ` Christophe Leroy (CS GROUP)
2026-07-31  5:03                             ` Christophe Leroy (CS GROUP)
2026-07-31  7:18                               ` Jirka Hladky
2026-07-31  8:02                                 ` Shrikanth Hegde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57d9de4a-65aa-44cf-9024-de4e5bdd1971@linux.ibm.com \
    --to=sshegde@linux.ibm.com \
    --cc=bigeasy@linutronix.de \
    --cc=christophe.leroy@csgroup.eu \
    --cc=jhladky@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox