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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87wmbsrwca.ffs@tglx>
Date: Thu, 10 Apr 2025 15:15:49 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Frederic Weisbecker <frederic@...nel.org>, Gabriele Monaco
 <gmonaco@...hat.com>
Cc: linux-kernel@...r.kernel.org, Waiman Long <longman@...hat.com>
Subject: Re: [PATCH] timers: Exclude isolated cpus from timer migation

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