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: <77988036-7550-4ee2-a738-9f9bd4417001@redhat.com>
Date: Thu, 10 Apr 2025 10:35:55 -0400
From: Waiman Long <llong@...hat.com>
To: Frederic Weisbecker <frederic@...nel.org>,
 Gabriele Monaco <gmonaco@...hat.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] timers: Exclude isolated cpus from timer migation

On 4/10/25 9:03 AM, Frederic Weisbecker wrote:
> Le Thu, Apr 10, 2025 at 12:38:25PM +0200, Gabriele Monaco a écrit :
>> On Thu, 2025-04-10 at 10:26 +0200, Thomas Gleixner wrote:
>>> How can that happen? There is always at least _ONE_ housekeeping,
>>> non-isolated, CPU online, no?
>>>
>> In my understanding it shouldn't, but I'm not sure there's anything
>> preventing the user from isolating everything via cpuset.
>> Anyway that's something no one in their mind should do, so I guess I'd
>> just opt for the cpumask_first (or actually cpumask_any, like before
>> the change).
> With "nohz_full=..." or "isolcpus=nohz,..." there is always at least one
> housekeeping CPU. But with isolcpus=[domain] or cpusets equivalents
> (v1 cpuset.sched_load_balance, v2 isolated partion) there is nothing that
> prevents all CPUs from being isolated.

Actually v2 won't allow users to isolate all the CPUs. Users can 
probably do that with v1's cpuset.sched_load_balance.

Cheers,
Longman