Re: [PATCH v6 6/6] timers: Exclude isolated cpus from timer migation

[Gabriele Monaco <gmonaco@redhat.com>]

On Tue, 2025-06-24 at 15:20 +0200, Thomas Gleixner wrote:
> On Tue, Jun 24 2025 at 10:05, Gabriele Monaco wrote:
> 
> Please trim your replies. It's a pain to scroll through 160 quotes
> lines
> to find the gist of the mail...
> 
> > On Fri, 2025-06-20 at 19:00 +0200, Thomas Gleixner wrote:
> > > > +	if ((!housekeeping_cpu(cpu, HK_TYPE_DOMAIN) ||
> > > > +	     cpuset_cpu_is_isolated(cpu)) &&
> > > > +	    housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE) &&
> > > > +	    tick_nohz_cpu_hotpluggable(cpu))
> > > > +		return 0;
> > > 
> > > Same nonsense as above.
> > > 
> > tmigr_cpu_available is called at boot time and is applying also the
> > boot time isolation parameters (tmigr_isolated_exclude_cpumask is
> > only
> > used by the cpuset code).
> > 
> > Now let's assume a machine booted with the arguments isolcpus=0-3
> > nohz_full=5-7.
> > 
> > Without checking for tick_nohz_cpu_hotpluggable() here, we would
> > not
> > set the tick cpu (0) as available at boot, ending up in the
> > unwanted
> > corner cases discussed in the v5 of the series.
> > 
> > I could remove this call here (which is mostly redundant after
> > boot)
> > and enable explicitly the tick cpu in another way, but this still
> > seems
> > cleaner to me.
> > 
> > Does it make sense to you? Is the comment in the code unclear?
> 
> It does not make sense and the comment does not change that.
> 
> The point is that tmigr_init() is an early initcall which is invoked
> before SMP is initialized and APs are brought up.
> 
> At this point CPU0 can neither be isolated nor nohz full for obvious
> reasons, no?
> 

Right, but as far as I understood, the first call to 
tmigr_set_cpu_available() happens after the isolcpus parameter has been
parsed so we know at least cpu0 is going to be isolated.

On my machine it works reliably this way. I'm a bit lost in the init
code but seeing housekeeping_init() before rcu_init(), which in turn
should be required for some RCU-related early_initcalls, makes me
believe this order is guaranteed to be respected.
Or am I missing something?

Thanks,
Gabriele