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_fcv6CrHk0Qa9HV@localhost.localdomain>
Date: Thu, 10 Apr 2025 16:59:11 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, 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:10PM +0200, Gabriele Monaco a écrit :
> 
> 
> On Thu, 2025-04-10 at 16:20 +0200, 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.
> > 
> > > Wouldn't that be sufficient?
> > > 
> > > Also, I would definitely do 1. for any kind of isolation, but I'm
> > > not
> > > sure about 2.
> > > Strictly speaking domain isolated cores don't claim to be free of
> > > kernel noise, even if they initiate it (but nohz_full ones do).
> > > What would be the expectation there?
> > 
> > I don't know, I haven't heard complains about isolcpus handling
> > global
> > timers so far...
> > 
> > I wouldn't pay much attention to 2) until anybody complains. Does 1)
> > even
> > matter to anybody outside nohz_full ?
> > 
> 
> Makes sense..
> In our case, 2. is not a big issue because it can usually be solved by
> other configurations, but 1. is an issue.
> Most people indeed use nohz_full in that scenario, but some users may
> not want its overhead.
> 
> I find it misleading at best for global timers to migrate from
> housekeeping to isolcpus cores and since it's "easy", I'd definitely
> change that.

Easy but still a bit invasive so:

> Does it make sense?

It makes sense but is there a real need for that? Have people
complained about that?

Thanks.

> 
> Thanks,
> Gabriele
> 

-- 
Frederic Weisbecker
SUSE Labs