linux-kernel - Re: [PATCH 4/4] sched/fair: Remove atomic nr

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] [day] [month] [year] [list]

Message-ID: <aS8QUIQ8smrDTuxr@gmail.com>
Date: Tue, 2 Dec 2025 17:14:08 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>
Cc: peterz@...radead.org, vincent.guittot@...aro.org,
	linux-kernel@...r.kernel.org, kprateek.nayak@....com,
	dietmar.eggemann@....com, vschneid@...hat.com, rostedt@...dmis.org,
	tglx@...utronix.de, tim.c.chen@...ux.intel.com,
	Frederic Weisbecker <frederic@...nel.org>
Subject: Re: [PATCH 4/4] sched/fair: Remove atomic nr_cpus and use cpumask
 instead


* Shrikanth Hegde <sshegde@...ux.ibm.com> wrote:

> > So I'd argue that reductions in both (A) and (B) 
> > are useful, but for different reasons.
> > 
> > The *real* breakthrough in this area would be to 
> > reduce the unlimited upwards frequency of (2), by 
> > fundamentally changing the model of NOHZ idle 
> > balancing:
> > 
> > For example by measuring the rate (frequency) of 
> > idle cycles on each CPU (this can be done without 
> > any cross-CPU logic), we would turn off NOHZ-idle 
> > for that CPU when the rate goes beyond a threshold.
> > 
> > The resulting regular idle load-balancing passes 
> > will be rate-limited by balance intervals and won't 
> > be as aggressive as nohz_balance_enter+exit_idle(). 
> > (I hope...)
> > 
> > Truly idle CPUs would go into NOHZ mode 
> > automatically, as their measured rate of idling 
> > drops below the threshold.
> > 
> > Thoughts?
> 
> Interesting.
> 
> Let me see if i get this right.
> 
> So track the idle duration over certain past 
> interval. If is below certain threshould mark those 
> CPUs in nohz state while doing idle entry/exit. If 
> not, reset their bits in nohz mask and don't update 
> the mask?
> 
> I think rq->avg_idle there already and we do similar checks for newidle_balance.
> sched_balance_newidle
> ...
>         if (!get_rd_overloaded(this_rq->rd) ||
>             this_rq->avg_idle < sd->max_newidle_lb_cost) {
> 
>                 update_next_balance(sd, &next_balance);
>                 rcu_read_unlock();
>                 goto out;
>         }

Yeah, seems so - but I haven't put much thought into 
the idea, so caveat emptor. :-)

Thanks,

	Ingo