On Mon, May 15, 2023 at 7:26 PM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: > > 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. Thank Paul for solving my confusion. One paragraph of teaching solved my a year's puzzle ;-) Thanks again Zhouyi > > Thanx, Paul
