Re: [PATCH v4 1/1] powerpc: enable dynamic preemption
"Christophe Leroy (CS GROUP)" <[email protected]> Fri, 31 Jul 2026 07:03:02 +0200
| Newsgroups | org.ozlabs.lists.linuxppc-dev,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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 <[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. 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