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

[Thomas Gleixner]

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.

>> 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?

Thanks,

        tglx