Re: [PATCH v3 1/1] powerpc: Enable dynamic preemption

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2025-01-30 22:27:07 [+0530], Shrikanth Hegde wrote:
> > | #DEFINE need_irq_preemption() \
> > |          (static_branch_unlikely(&sk_dynamic_irqentry_exit_cond_resched))
> > |
> > | 	if (need_irq_preemption()) {
> > 
> > be a bit smaller/ quicker? This could be a fast path ;)
> 
> I am okay with either way. I did try both[1], there wasn't any significant difference,
> hence chose a simpler one. May be system size, workload pattern might matter.
> 
> Let me do some more testing to see which one wins.
> Is there any specific benchmark which might help here?

No idea. As per bean counting: preempt_model_preemptible() should
resolve in two function calls + conditional in the dynamic case. This
should be more expensive compared to a nop/ branch ;)
But you would still need preempt_model_preemptible() for the !DYN case.

> > > +	       preempt_model_voluntary() ? "voluntary" :
> > > +	       preempt_model_full()      ? "full" :
> > > +	       preempt_model_lazy()      ? "lazy" :
> > > +	       "",
> > 
> > So intend to rework this part. I have patches stashed at
> > 	https://git.kernel.org/pub/scm/linux/kernel/git/bigeasy/staging.git/log/?h=preemption_string
> > 
> > which I didn't sent yet due to the merge window. Just a heads up ;)
> 
> Makes sense. I had seen at-least two places where this code was there, ftrace/powerpc.
> There were way more places..
> 
> You want me to remove this part?

No, just be aware.
I don't know how this will be routed I guess we merge the sched pieces
first and then I submit the other pieces via the relevant maintainer
tree. In that case please be aware that all parts get removed/ replaced
properly.

Sebastian