Hi Paul, Christophe, On 7/27/26 11:59 PM, Christophe Leroy (CS GROUP) wrote:
Hi Shrikanth,
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. 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. 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. 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. 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?
