linux-kernel - Re: [PATCH] sched/nohz: Fix NOHZ imbalance by adding options for ILB CPU

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: <aLrUgpOshn5mg6sL@localhost.localdomain>
Date: Fri, 5 Sep 2025 14:16:02 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: "Christoph Lameter (Ampere)" <cl@...two.org>
Cc: Valentin Schneider <vschneid@...hat.com>,
	Adam Li <adamli@...amperecomputing.com>, mingo@...hat.com,
	peterz@...radead.org, juri.lelli@...hat.com,
	vincent.guittot@...aro.org, dietmar.eggemann@....com,
	rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
	linux-kernel@...r.kernel.org, patches@...erecomputing.com
Subject: Re: [PATCH] sched/nohz: Fix NOHZ imbalance by adding options for ILB
 CPU

Le Thu, Sep 04, 2025 at 09:18:42AM -0700, Christoph Lameter (Ampere) a écrit :
> On Thu, 4 Sep 2025, Frederic Weisbecker wrote:
> 
> > > > That's an argument _not_ in favour of dynamic balancing such as ILB, even for
> > > > this usecase in nohz_full (all the other usecases of nohz_full I know really
> > > > want static affinity and no balancing at all).
> > > >
> > > > So I have to ask, what would be wrong with static affinities to these tasks?
> > >
> > > Static affinities are great but they keep the tick active and thus the
> > > rendevous can be off off one or the other compute thread.
> >
> > How do static affinities keep the tick active?
> 
> If you dont use hohz_full and only do static affinities then the tick is
> active.

If you don't use nohz_full then the tick is active, yes :-)

> My wish for the future would be that nohz_full would be the default and
> that the scheduler does correct load balancing regardless of the cpu being
> in tick mode or not.

Provided we ever manage to run nohz_full without tradeoffs (offloaded 1Hz tick,
RCU user/kernel overhead, cputime accounting overhead, use hrtick when
preemption must be maintained) then yes it would make sense but we are very
far from that. I'm not even sure this will ever be possible.

> It should automatically switch the tick off if a cpu
> goes into 100% compute and ideally there would be no performance
> regression if the tick is off.

Automatically means the kernel has to guess and make conclusion after some
execution time. That doesn't sound right, especially when nohz_full is used
with strong jitter-free guarantee, which has been the case for every usecases
so far.

Thanks.

-- 
Frederic Weisbecker
SUSE Labs