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_fHLM4nWP5XVGBU@localhost.localdomain>
Date: Thu, 10 Apr 2025 15:27:08 +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 03:15:49PM +0200, Thomas Gleixner a écrit :
> 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.

It works, but it doesn't make much sense arguably.

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

But how do we handle global timers that have been initialized and queued from
isolated CPUs?

Thanks.

-- 
Frederic Weisbecker
SUSE Labs