Re: [PATCH v2 2/3] sched/fair: Change likelyhood of nohz.nr_cpus and do stats update if its due

From: Shrikanth Hegde
Date: Mon Jan 05 2026 - 00:08:12 EST




On 1/5/26 9:22 AM, K Prateek Nayak wrote:
Hello Shrikanth,

On 1/2/2026 6:17 PM, Shrikanth Hegde wrote:
These days most of the system have multi cores. The likelyhood of
at least one or more CPUs in nohz (idle state) is higher.
So move likely to unlikely.

Allow stats balancing to complete when there are no nr_cpus as the check
happens later. This may do an additional stats based load balancing
which would reset has_blocked_load. Code also looks saner by removing
that uncharactiristic return in between.

Signed-off-by: Shrikanth Hegde <sshegde@xxxxxxxxxxxxx>
---
kernel/sched/fair.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index cd1c78d2c272..5ceb9126d441 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -12456,10 +12456,10 @@ static void nohz_balancer_kick(struct rq *rq)
/*
* None are in tickless mode and hence no need for NOHZ idle load
- * balancing:
+ * balancing, do stats update if its due
*/
- if (likely(!atomic_read(&nohz.nr_cpus)))
- return;
+ if (unlikely(!atomic_read(&nohz.nohz_balancer_kick)))
+ goto out;

Did something got edited here?

Since we are sure that "nohz.nr_cpus" is 0, there is a good chance
find_new_ilb() in kick_ilb() will not find any CPU to run balance on, so
why not just retain that return?

The "flags" can only be set to (NOHZ_NEXT_KICK | NOHZ_STATS_KICK) on
this path and kick_ilb() will simply return early without updating
"nohz.next_balance" when it doesn't see NOHZ_BALANCE_KICK and fails to
find any CPU. Might as well keep the early return.


The only reason why flags would be set is, if nohz.has_blocked_load
is set and time is after next_blocked. In that case, doing a stats
based balance will make nohz.has_blocked_load=0 and subsequent invocations
flags =0 and no load balance will happen if nr_cpus stays 0.

However, if we just, has_blocked_load might remains stale value.

Isn't that the case?