On Mon, May 15, 2023 at 09:55:02AM +0800, Zhouyi Zhou wrote: > Dear RCUers: > > When I study the function rcu_nocb_try_bypass, the only place it can > be called is from > function __call_rcu_common, and __call_rcu_common disable irq before > call rcu_nocb_try_bypass, so, I assume when we enter > rcu_nocb_try_bypass, there will be no > context switch. > > In rcu_nocb_try_bypass, rcu_nocb_wait_contended got called, the > purpose of rcu_nocb_wait_contended is "relying on the fact that at > most two kthreads and one CPU contend for this lock". > > My question is: assume there will be no context switch, why will there > be two kthreads competing for this CPU lock? > > I have stumbled on this question for more than a year. > > Thank you all in advance ;-) In kernels built with CONFIG_RCU_NOCB_CPU=y and on CPUs selected by either the nohz_full or rcu_nocbs kernel boot parameters, callbacks are invoked by "rcuo" kthreads created for this purpose. These kthreads might run on any CPU, and so you can have the CPU queuing the callback contending with the CPU running the corresponding "rcuo" kthread. Thanx, Paul
