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

[Frederic Weisbecker <frederic@kernel.org>]

Le Thu, Apr 10, 2025 at 03:15:49PM +0200, Thomas Gleixner a écrit :
> On Thu, Apr 10 2025 at 15:03, Frederic Weisbecker wrote:
> > Le Thu, Apr 10, 2025 at 12:38:25PM +0200, Gabriele Monaco a écrit :
> > Speaking of, those are two different issues here:
> >
> > * nohz_full CPUs are handled just like idle CPUs. Once the tick is stopped,
> >   the global timers are handled by other CPUs (housekeeping). There is always
> >   one housekeeping CPU that never goes idle.
> >   One subtle thing though: if the nohz_full CPU fires a tick, because there
> >   is a local timer to be handled for example, it will also possibly handle
> >   some global timers along the way. If it happens to be a problem, it should
> >   be easy to resolve.
> >
> > * Domain isolated CPUs are treated just like other CPUs. But there is not
> >   always a housekeeping CPU around. And no guarantee that there is always
> >   a non-idle CPU to take care of global timers.
> 
> That's an insianity.

It works, but it doesn't make much sense arguably.

> 
> >> Thinking about it now, since global timers /can/ start on isolated
> >> cores, that makes them quite different from offline ones and probably
> >> considering them the same is just not the right thing to do..
> >> 
> >> I'm going to have a deeper thought about this whole approach, perhaps
> >> something simpler just preventing migration in that one direction would
> >> suffice.
> >
> > I think we can use your solution, which involves isolating the CPU from tmigr
> > hierarchy. And also always queue global timers to non-isolated targets.
> 
> Why do we have to inflict extra complexity into the timer enqueue path
> instead of preventing the migration to, but not the migration from
> isolated CPUs?

But how do we handle global timers that have been initialized and queued from
isolated CPUs?

Thanks.

-- 
Frederic Weisbecker
SUSE Labs