[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260102124744.360872-1-sshegde@linux.ibm.com>
Date: Fri, 2 Jan 2026 18:17:41 +0530
From: Shrikanth Hegde <sshegde@...ux.ibm.com>
To: mingo@...nel.org, peterz@...radead.org, vincent.guittot@...aro.org
Cc: sshegde@...ux.ibm.com, linux-kernel@...r.kernel.org,
kprateek.nayak@....com, juri.lelli@...hat.com, vschneid@...hat.com,
tglx@...utronix.de, dietmar.eggemann@....com, anna-maria@...utronix.de,
frederic@...nel.org, wangyang.guo@...el.com
Subject: [PATCH v2 0/3] sched/fair: improve nohz fields for large systems
Running on large systems nohz.nr_cpus cacheline was seen as contended.
There is atomic inc/dec and read happening on many
CPUs at a time and it is possible for this line to bounce often.
Gist of the series is to get rid of nr_cpus. Instead, use the cpumask
which is always updated alongside with it. Functionally it should serve
the same purpose. Rest of the fields aren't updated that often. So this
line shouldn't bounce that often.
Contention issue with nohz.idle_cpus_mask still remains. Mostly it is in
separate cacheline than nohz. There are ongoing efforts to mitigate it. It
is not addressed by this series.
v1 -> v2:
- Dropped patch to check has_blocked based on time.
- Detailed changelog for removing nr_cpus (Thanks to Ingo Molnar)
v1: https://lore.kernel.org/all/20251201183146.74443-1-sshegde@linux.ibm.com/
Shrikanth Hegde (3):
sched/fair: Move checking for nohz cpus after time check
sched/fair: Change likelyhood of nohz.nr_cpus and do stats update if
its due
sched/fair: Remove nohz.nr_cpus and use weight of cpumask instead
kernel/sched/fair.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
--
2.47.3
Powered by blists - more mailing lists