Re: [PATCH v11 8/8] timers: Exclude isolated cpus from timer migration

[Gabriele Monaco <gmonaco@redhat.com>]

On Tue, 2025-09-02 at 14:45 +0200, Frederic Weisbecker wrote:
> > On Mon, 2025-09-01 at 23:11 +0200, Frederic Weisbecker wrote:
> > > Right, Thomas didn't like it, but the organization of the code
> > > has changed a bit since then with the late initcall. If the best
> > > we can do to workaround the situation is to make the CPU
> > > unavailable regardless and then undo that right after with an
> > > IPI, then it's a good sign that we should just simplify and
> > > eventually check tick_nohz_cpu_hotpluggable() from
> > > tmigr_is_isolated().
> > Here I'm a bit unsure how to proceed though. We want to fail any
> > single isolated cpuset that includes the tick CPU under nohz_full.
> > I can do it directly in isolcpus_nohz_conflict and that looks easy.
> > 
> > But is that going to be clear for the user?
> > Can the user even know what the tick CPU is? Besides /assuming/ 0.
> 
> You're right the user can't know in advance which CPU is the tick.
> I don't mind if we prevent or not cpuset from allowing to isolate
> the timekeeper but either way, a pr_info() could be helpful to tell
> that either:
> 
> * The isolated timekeeper will have limited isolation
> or
> * The timekeeper can't be isolated.
> 

As far as I understand, we are now decided to fail cpuset isolated
assignments involving the tick CPU when nohz_full is active.

What prevents us from doing the same in the isolcpus code?
Or at least un-isolate the tick cpu like it happens for nohz_full?

The patch currently avoids the tick CPU in the isolated tmigr logic but
allows it anywhere else.
I believe if we are changing this, cpusets and isolcpus should at least
be consistent.

I remember I went down this path because it was mentioned the tick CPU
is allowed to change. Is this really a concern when nohz_full is
active?

If the tick CPU can change after boot, we would probably need to track
this change either way (in tmigr or isolation/cpuset), but it doesn't
seem the case to me.

If we guarantee the tick cpu is never isolated, we can get rid of the
tick_nohz_cpu_hotpluggable() check for good.

Am I missing anything?

Thanks,
Gabriele