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
