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: <Z_fZJfgwzpz_ccny@localhost.localdomain>
Date: Thu, 10 Apr 2025 16:43:49 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Waiman Long <llong@...hat.com>
Cc: Gabriele Monaco <gmonaco@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] timers: Exclude isolated cpus from timer migation

Le Thu, Apr 10, 2025 at 10:35:55AM -0400, Waiman Long a écrit :
> 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.

Perhaps, and I think isolcpus= can too.

-- 
Frederic Weisbecker
SUSE Labs