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 for Android: free password hash cracker in your pocket

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

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

Le Thu, Apr 10, 2025 at 04:46:06PM +0200, Thomas Gleixner a écrit :
> On Thu, Apr 10 2025 at 16:20, Frederic Weisbecker wrote:
> > Le Thu, Apr 10, 2025 at 03:56:02PM +0200, Gabriele Monaco a écrit :
> >> On Thu, 2025-04-10 at 15:27 +0200, Frederic Weisbecker wrote:
> >> > But how do we handle global timers that have been initialized and
> >> > queued from
> >> > isolated CPUs?
> >> 
> >> I need to sketch a bit more the solution but the rough idea is:
> >> 1. isolated CPUs don't pull remote timers
> >
> > That's the "easy" part.
> >
> >> 2. isolated CPUs ignore their global timers and let others pull them
> >>   perhaps with some more logic to avoid it expiring
> >
> > This will always involve added overhead because you may need to wake up
> > a CPU upon enqueueing a global timer to make sure it will be handled.
> > At least when all other CPUs are idle.
> 
> Which is true for the remote enqueue path too. But you inflict the
> handling of this muck into the generic enqueue path as you have to turn
> a 'global' timer into a remote timer right in the hot path.

Fair point.

> 
> When you enqueue it in the regular way on the 'global' list, then you
> can delegate the expiry to a remote CPU on return to user, no?

If you're referring to nohz_full, it's not a problem there because
it's already considered as an idle CPU.

But for isolcpus alone that notification is necessary. I'm not sure
if return to user is the best place. I hear that some kernel threads
can spend a lot of time doing things...

But to begin with, is this all really necessary for isolcpus users?

-- 
Frederic Weisbecker
SUSE Labs