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.
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
it is probably not best possible setting but it is easy and simple to
try out to see if it fix my problem.
