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: <56eae8396c5531b7a92a8e9e329ad68628e53729.camel@redhat.com>
Date: Thu, 10 Apr 2025 16:46:10 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: Frederic Weisbecker <frederic@...nel.org>
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



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.

Does it make sense?

Thanks,
Gabriele