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

On Tue, Jul 28, 2026 at 09:21:55AM -0700, Paul E. McKenney wrote:

On Tue, Jul 28, 2026 at 10:57:57AM +0530, Shrikanth Hegde wrote:

quoted

Hi Paul, Christophe,

On 7/27/26 11:59 PM, Christophe Leroy (CS GROUP) wrote:

quoted

Hi Shrikanth,

quoted

That's right with CONFIG_PREEMPT_DYNAMIC=y

With CONFIG_PREEMT_DYNAMIC=n:
- CONFIG_PREEMPT (full) implies CONFIG_PREEMPT_RCU
- CONFIG_PREEMPT_LAZY (lazy) doesn't imply CONFIG_PREEMPT_RCU

because of kernel/rcu/Kconfig,

config PREEMPT_RCU
     bool
     default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC)
     select TREE_RCU

Christophe

Right.

Looks like __rcu_read_unlock can set need_resched bit if it find irq were disabled
and rcu_read_unlock_special.s is set. I don't have much clue about it.
So, after seeing __rcu_read_unlock for PREEMPT_RCU I have these concerns now.

This is because irq-disabled regions of code act as RCU readers.
For non-preemptible RCU (even in CONFIG_PREEMPT_LAZY=y kernels), this
comes for free.  In contrast, preemptible RCU must explicitly (and,
as you noticed, rather painfully) handle the irq-disabled case:

	rcu_read_lock();
	do_something();
	local_irq_disable();
	do_something_else();
	rcu_read_unlock();
	do_yet_another_thing();
	local_irq_enable();

Here, the RCU reader extends all the way from the rcu_read_lock() to
the final local_irq_enable().  And this is why RCU checks for IRQs being
disabled in __rcu_read_unlock().

quoted

In current upstream, lazy is a preemption mode with preempt_enable being a preemptible point,

1. If PREEMPT_LAZY=y and PREEMPT_DYNAMIC=n, then PREEMPT_RCU=n. That seems wrong. It is supposed to
   do the preemption checks, since preempt_count is actual count with lazy preemption.

Sorry, but no, not wrong at all.  This is the way that it is supposed
to be.  In this configuration, RCU readers explicitly disable preemption.
This gets us minimal RCU overhead on architectures such as x86 and arm64
that have prohibited CONFIG_PREEMPT_NONE and CONFIG_PREEMPT_VOLUNTARY.
Not zero overhead, but minimal overhead given the constraints imposed by
CONFIG_PREEMPT_LAZY.  This also prevents preemption of RCU readers, which
is extremely important on datacenter servers that have good and sufficient
quantities of memory, but which are not well-endowed with memory.

Now, if you would like to be able to manually choose between non-preemptible
and preemptible RCU when when PREEMPT_LAZY=y, *that* we could discuss.

But it looks like you are looking for low overhead, and thus wanting to
avoid preemptible RCU.

							Thanx, Paul

quoted

2. PREEMPT_LAZY=y and PREEMPT_DYNAMIC=n and PREEMPT_LAZY=y and PREEMPT_DYNAMIC=y are supposed
   to be similar w.r.t to performance.

RCU never made that promise.  ;-)

With PREMPT_DYNAMIC=y, RCU has no choice but to be preemptible, at
least unless and until someone decides to make RCU's preemptibility be
changeable at runtime (which I do not recommend).  And we really do need
non-preemptible RCU for server workloads.

So it is not just that RCU never made that promise, it is that RCU cannot
reasonably make that promise.

quoted

                                       Promise of PREEMPT_DYNAMIC was the ability to
   switch at runtime based on the user workload and his/her preference.
   But with  PREEMPT_LAZY=y and PREEMPT_DYNAMIC=y, there is additional cost due to PREEMPT_RCU.
   lazy being the middle ground w.r.t for decent performance, either PREEMPT_RCU should either kick in
   for both cases or bail out for both.

Absolutely not!!!  Please see above.

quoted

Before 7.0
3. the same concerns would be true to PREEMPT_VOLUNTARY and PREEMPT_NONE with PREEMPT_DYNAMIC=y.
   Those model never wanted a preemption, but PREEMPT_RCU could have forced a need_resched to be
   set. Which is also likely wrong. No?

You lost me on this one.  Please give me an explicit sequence of events
that would cause things to go wrong in this case.

							Thanx, Paul