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

"Paul E. McKenney" <[email protected]> Mon, 3 Aug 2026 08:27:47 -0700
Newsgroups org.ozlabs.lists.linuxppc-dev,org.kernel.vger.linux-kernel
Message-ID <a98d7587-d9de-47c3-aa2e-0c9d9df0acf5@paulmck-laptop>
On Mon, Aug 03, 2026 at 10:21:26AM +0530, Shrikanth Hegde wrote:
> 
> Hi Paul,
> 
> > > I tried moving to PACA plus splitting 64 bit into need_resched and preempt
> > > count. But it doesn;t move the needle. But it maybe worth pursuing,
> > > since it could help preemption modes. It needs more work and needs numbers
> > > across benchmark.
> > > 
> > > > Thanks for trying. Paul questioned whether barriers are actually
> > > > needed for preempt_count, or whether software interrupt disabling
> > > > would suffice (his words: "I can see why the preempt_count()
> > > > operations need to be interrupt-safe, but I don't see why you would
> > > > need barriers"). Any thoughts on whether that's feasible for
> > > > powerpc?
> > > 
> > > Barrier are likely not the concern as it is mostly nop.
> > > Also, soft disabling interrupts needs to arch specific hooks to setup
> > > before preempt_disable and replay interrupts after preempt_enable.
> > > I don't think it would benefit since interrupt disabling during this likely
> > > shouldn't happen. Maybe I don't understand how that could work.
> > 
> > For some reason, I remembered powerpc software-disabling interrupts,
> > but when I go look now, there is no such thing.  Maybe powerpc used to
> > but no longer does.  Or maybe I am just hallucinating.  ;-)
> > 
> > 							Thanx, Paul
> 
> It is there still,
> 
> static inline unsigned long arch_local_irq_save(void)
> {
>         return irq_soft_mask_or_return(IRQS_DISABLED);
> }
> Sets the softmask bit, and any interrupt that arrives,
> gets added to a list and that will be replayed in arch_local_irq_restore.
> 
> That will protect against the race of irq vs preempt count in
> __preempt_count_dec_and_test. In the PACA based PoC i have i tried to use it,
> but it doesn't make a difference, since this particular test accounts mainly
> preempt count overhead itself, which cannot be escaped in dynamic preemption.
> 
> So, I think this is the tax we got to live with for dynamic preemption on RISC archs.
> But good thing is, its effect is limited to a very few microbenchmarks.

OK, I guess I just didn't look hard enough.  ;-)

And glad that the blast radius is limited.

							Thanx, Paul