Linux Power Management development
 help / color / mirror / Atom feed
From: Muhammad Usama Anjum <usama.anjum@arm.com>
To: Christian Loehle <christian.loehle@arm.com>
Cc: usama.anjum@arm.com, Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Valentin Schneider <vschneid@redhat.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Beata Michalska <beata.michalska@arm.com>,
	Elif Topuz <elif.topuz@arm.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Daniel Lezcano <daniel.lezcano@kernel.org>,
	Shubhang Kaushik <sh@gentwo.org>,
	Christoph Lameter <cl@gentwo.org>,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>
Subject: Re: [PATCH 0/2] sched/fair: Randomize equally shallow idle CPU picks
Date: Thu, 24 Sep 2026 13:44:50 +0100	[thread overview]
Message-ID: <c918c068-bf55-492f-bb7c-fcf02b8c661b@arm.com> (raw)
In-Reply-To: <20260916100116.701206-1-christian.loehle@arm.com>

On 16/09/2026 11:01 am, Christian Loehle wrote:
> Concurrent slow-path selectors can converge on the same idle CPU before
> either task is enqueued. Remove the idle-recency preference and randomize
> equal-latency choices in a single scan.
> 
> The testing platform 160-CPU, dual-socket Altra has unusually large 80-CPU
> candidate groups at NUMA level, making this particularly prone to stale
> idle picks.
> 
> Median stress-ng throughput (bogo ops/s):
> 
>   --fork  --fork-max      Baseline       Patched    Change
>   ------------------------------------------------------
>        1           1        779.19        811.38    +4.13%
>        8           1       2958.32       2960.18    +0.06%
>       16           1       5070.95       5247.63    +3.48%
>       16           4       7692.64       7831.60    +1.81%
>       32           1       8662.82       8643.39    -0.22%
>       64           1      11880.47      12096.69    +1.82%
> 
> Separate instrumented runs observed lower conditional stale-pick rates,
> i.e. a busy candidate at final return:
> 
> Workload                Baseline       Patched
> ----------------------------------------------
> fork, 32 creators          0.771%       0.407%
> fork, 64 creators          1.242%       0.672%


Fastpath runs repeatable Linux kernel benchmarks. Higher is better; (I)
marks a statistically significant improvement, (R) a regression, and an
unmarked value no significant change. These comparisons use a zero noise
threshold and Fastpath's default 95% confidence interval.

Results for SUT Class aws-m7g.metal:
+---------------------------------+----------------------------------------+---------------------------------------------
| Benchmark                       | Result Class                           |   v7.3-rc4 (base) |   v7.3-rc4-chr-idle-v2 |
+=================================+========================================+=============================================
| repro-collection/mysql-workload | db transaction rate (transactions/min) |    244098.17      |        -0.02%          |
|                                 | new order rate (orders/min)            |     80570.33      |        -0.08%          |
+---------------------------------+----------------------------------------+---------------------------------------------

Results for SUT multi node aws-m7g.metal + m7gd.12xlarge: (Pleaes note that these two instances are not placed in a placement group so networking could be a bottleneck in this case.)
+---------------------------------+----------------------------------------+---------------------------------------------
| Benchmark                       | Result Class                           |   v7.3-rc4 (base) |   v7.3-rc4-chr-idle-v2 |
+=================================+========================================+=============================================
| repro-collection/mysql-workload | db transaction rate (transactions/min) |      231145.00    |           0.03%        |
|                                 | new order rate (orders/min)            |       76208.00    |           0.05%        |
+---------------------------------+----------------------------------------+---------------------------------------------

Hence:
Tested-by: Muhammad Usama Anjum <usama.anjum@arm.com>

> 
> Christian Loehle (2):
>   sched/fair: Drop idle recency from slow-path CPU selection
>   sched/fair: Randomize equally shallow slow-path candidates
> 
>  kernel/sched/fair.c | 24 ++++++++----------------
>  1 file changed, 8 insertions(+), 16 deletions(-)
> 
> 
> base-commit: fd73f4a6659897191fa0d40695fe370925dd3780


-- 
Thanks,
Usama

      parent reply	other threads:[~2026-09-24 12:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16 10:01 [PATCH 0/2] sched/fair: Randomize equally shallow idle CPU picks Christian Loehle
2026-09-16 10:01 ` [PATCH 1/2] sched/fair: Drop idle recency from slow-path CPU selection Christian Loehle
2026-09-17 13:28   ` Vincent Guittot
2026-09-16 10:01 ` [PATCH 2/2] sched/fair: Randomize equally shallow slow-path candidates Christian Loehle
2026-09-16 11:06   ` Kayra Cizmeci
2026-09-16 11:10     ` Christian Loehle
2026-09-16 11:12   ` Christian Loehle
2026-09-16 11:46     ` Kayra Cizmeci
2026-09-16 19:43   ` Shubhang
2026-09-17  7:47     ` Christian Loehle
2026-09-17  9:58       ` Christian Loehle
2026-09-17 14:02         ` Vincent Guittot
2026-09-17 14:16         ` Kayra Cizmeci
2026-09-17 14:08   ` Vincent Guittot
2026-09-17 14:22     ` Christian Loehle
2026-09-17 15:08       ` Vincent Guittot
2026-09-17 15:17         ` Christian Loehle
2026-09-24 12:44 ` Muhammad Usama Anjum [this message]

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=c918c068-bf55-492f-bb7c-fcf02b8c661b@arm.com \
    --to=usama.anjum@arm.com \
    --cc=beata.michalska@arm.com \
    --cc=christian.loehle@arm.com \
    --cc=cl@gentwo.org \
    --cc=daniel.lezcano@kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=elif.topuz@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sh@gentwo.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