public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Imran Khan <imran.f.khan@oracle.com>
To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	vincent.guittot@linaro.org
Cc: dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
	linux-kernel@vger.kernel.org
Subject: [PATCH 0/2] sched/fair: Reduce nohz_idle_balance CPU overhead on large systems
Date: Tue, 21 Apr 2026 13:06:20 +0800	[thread overview]
Message-ID: <20260421050622.19869-1-imran.f.khan@oracle.com> (raw)

On large systems (700+ CPUs, 350+ CPUs in root sched_domain/cpuset),
nohz idle balancing can consume significant amount of CPU due to two
independent problems.

First, due to large number of CPUs there is a very good chance of
nohz.next_balance always being same or very close to current jiffies,
causing nohz idle balance work to happen on almost each tick.

Second, find_new_ilb() uses for_each_cpu_and() to iterate idle_cpus_mask
from the lowest bit, so the lowest-numbered idle CPU in the cpuset bears
the full burden of nohz ILB work and most of the times it's the same CPU.
Again on large scale systems this work becomes significant and unfairly
consumes cycles of same CPU most of the times.

Patch 1 addresses the first issue by advancing nohz.next_balance based on
the number of idle CPUs and patch 2 addresses the second issue by
distributing the nohz ILB work across eligible idle CPUs.

Imran Khan (2):
  sched/fair: scale nohz.next_balance according to number of idle CPUs.
  sched/fair: distribute nohz ILB work across idle CPUs.

 kernel/sched/fair.c | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)


base-commit: 591cd656a1bf5ea94a222af5ef2ee76df029c1d2
-- 
2.34.1


             reply	other threads:[~2026-04-21  5:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-21  5:06 Imran Khan [this message]
2026-04-21  5:06 ` [PATCH 1/2] sched/fair: scale nohz.next_balance according to number of idle CPUs Imran Khan
2026-04-21 17:30   ` Shrikanth Hegde
2026-04-22  7:54   ` Vincent Guittot
2026-04-22 16:13     ` imran.f.khan
2026-04-24  9:46       ` Vincent Guittot
2026-04-28 10:52         ` imran.f.khan
2026-04-28 15:06           ` Vincent Guittot
2026-04-21  5:06 ` [PATCH 2/2] sched/fair: distribute nohz ILB work across " Imran Khan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260421050622.19869-1-imran.f.khan@oracle.com \
    --to=imran.f.khan@oracle.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox