On Thu, Aug 01, 2024 at 01:34:21PM -0400, Olivier Langlois wrote: > On Thu, 2024-08-01 at 12:32 -0400, Olivier Langlois wrote: > > > > > > This is the kthread that invokes the callbacks for CPU 1, assuming > > > you > > > have a non-preemptible kernel (otherwise rcuop/1 for historical > > > reasons > > > that seemed like a good idea at the time). Do you also have an > > > rcuos/2? > > > (See the help text for CONFIG_RCU_NOCB_CPU.) > > > > yes I do. > > > > $ ps -eo pid,cpuid,comm | grep rcu > > 4 0 kworker/R-rcu_gp > > 8 0 kworker/0:0-rcu_gp > > 14 0 rcu_tasks_rude_kthread > > 15 0 rcu_tasks_trace_kthread > > 17 3 rcu_sched > > 18 3 rcuog/0 > > 19 0 rcuos/0 > > 20 0 rcu_exp_par_gp_kthread_worker/0 > > 21 3 rcu_exp_gp_kthread_worker > > 31 3 rcuos/1 > > 38 3 rcuog/2 > > 39 3 rcuos/2 > > 46 0 rcuos/3 > > > > and yes my kernel is built without CONFIG_PREEMPT. Since my system > > consists of 3 isolated cpus out of 4, I have figured that there was > > not > > much to preempt for the overhead coming along with the feature. > > > > but here again, I am thankful for the cue... If all else fail, > > running > > the setup with CONFIG_PREEMPT enabled to see if it change anything, > > this might be something interesting to try. > > I have just set rcutree.rcu_nocb_gp_stride=4. > > $ ps -eo pid,cpuid,comm | grep rcu > 4 0 kworker/R-rcu_gp > 8 0 kworker/0:0-rcu_gp > 14 0 rcu_tasks_rude_kthread > 15 0 rcu_tasks_trace_kthread > 17 3 rcu_sched > 18 3 rcuog/0 > 19 0 rcuos/0 > 20 0 rcu_exp_par_gp_kthread_worker/0 > 21 3 rcu_exp_gp_kthread_worker > 31 3 rcuos/1 > 38 0 rcuos/2 > 45 0 rcuos/3 > > this different setting did not eliminate the sporadic IWI and LOC > interrupts on CPU1 > > I think that I have misunderstood the explanation about the RCU kthread > groups. I thought that this setting would add a rcuog process for CPU1. This presentation might be helpful: https://www.youtube.com/watch?v=5yTf7u5J_kc > you didn't seem concerned that rcuog was missing for cpu1. > rcutree.rcu_nocb_gp_stride sets the group size (stride) and there is 1 > rcuog per group. I guess if I wanted to see a rcuog/1, I would need to > set rcutree.rcu_nocb_gp_stride=1 The grace-period functions of the lead rcuos kthreads have been pushed off into a smaller number of rcuog kthreads. Which is why you do not (repeat, *not*) have an rcuog kthread for each CPU. > it is probably not best possible setting but it is easy and simple to > try out to see if it fix my problem. You probably do not want an rcuog kthread for each CPU, but it cannot hurt to try it. Thanx, Paul
