From: K Prateek Nayak <kprateek.nayak@amd.com>
To: John Stultz <jstultz@google.com>, LKML <linux-kernel@vger.kernel.org>
Cc: Joel Fernandes <joelagnelf@nvidia.com>,
Qais Yousef <qyousef@layalina.io>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Valentin Schneider <vschneid@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>,
Zimuzo Ezeozue <zezeozue@google.com>,
Mel Gorman <mgorman@suse.de>, Will Deacon <will@kernel.org>,
Waiman Long <longman@redhat.com>,
Boqun Feng <boqun.feng@gmail.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Metin Kaya <Metin.Kaya@arm.com>,
Xuewen Yan <xuewen.yan94@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Suleiman Souhlal <suleiman@google.com>,
kuyo chang <kuyo.chang@mediatek.com>, hupu <hupu.gm@gmail.com>,
kernel-team@android.com
Subject: Re: [PATCH v18 0/8] Single RunQueue Proxy Execution (v18)
Date: Fri, 27 Jun 2025 08:34:49 +0530 [thread overview]
Message-ID: <a8de5df6-665d-4c97-aff9-854ccc49adfc@amd.com> (raw)
In-Reply-To: <20250625203110.2299275-1-jstultz@google.com>
Hello John,
On 6/26/2025 2:00 AM, John Stultz wrote:
> Hey All,
>
> After not getting much response from the v17 series (and
> resending it), I was going to continue to just iterate resending
> the v17 single runqueue focused series. However, Suleiman had a
> very good suggestion for improving the larger patch series and a
> few of the tweaks for those changes trickled back into the set
> I’m submitting here.
>
> Unfortunately those later changes also uncovered some stability
> problems with the full proxy-exec patch series, which took a
> painfully long time (stress testing taking 30-60 hours to trip
> the problem) to resolve. However, after finally sorting those
> issues out it has been running well, so I can now send out the
> next revision (v18) of the set.
>
> So here is v18 of the Proxy Execution series, a generalized form
> of priority inheritance.
Sorry for the lack of response on the previous version but here
are the test results for v18.
tl;dr I don't see anything major. Few regressions I see are for
data points with lot of deviation so I think they can be safely
ignored.
Full results are below:
o Machine details
- 3rd Generation EPYC System
- 2 sockets each with 64C/128T
- NPS1 (Each socket is a NUMA node)
- C2 Disabled (POLL and C1(MWAIT) remained enabled)
o Kernel details
tip: tip:sched/urgentat commit 914873bc7df9 ("Merge tag
'x86-build-2025-05-25' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
proxy_exec: tip + this series as is with CONFIG_SCHED_PROXY_EXEC=y
o Benchmark results
==================================================================
Test : hackbench
Units : Normalized time in seconds
Interpretation: Lower is better
Statistic : AMean
==================================================================
Case: tip[pct imp](CV) proxy_exec[pct imp](CV)
1-groups 1.00 [ -0.00](13.74) 1.03 [ -3.20]( 8.80)
2-groups 1.00 [ -0.00]( 9.58) 1.04 [ -4.45]( 6.58)
4-groups 1.00 [ -0.00]( 2.10) 1.02 [ -2.17]( 1.85)
8-groups 1.00 [ -0.00]( 1.51) 0.99 [ 1.42]( 1.47)
16-groups 1.00 [ -0.00]( 1.10) 1.00 [ 0.42]( 1.23)
==================================================================
Test : tbench
Units : Normalized throughput
Interpretation: Higher is better
Statistic : AMean
==================================================================
Clients: tip[pct imp](CV) proxy_exec[pct imp](CV)
1 1.00 [ 0.00]( 0.82) 1.02 [ 1.78]( 1.06)
2 1.00 [ 0.00]( 1.13) 1.03 [ 3.30]( 1.05)
4 1.00 [ 0.00]( 1.12) 1.02 [ 1.86]( 1.05)
8 1.00 [ 0.00]( 0.93) 1.02 [ 1.74]( 0.72)
16 1.00 [ 0.00]( 0.38) 1.02 [ 2.28]( 1.35)
32 1.00 [ 0.00]( 0.66) 1.01 [ 1.44]( 0.85)
64 1.00 [ 0.00]( 1.18) 1.02 [ 1.98]( 1.28)
128 1.00 [ 0.00]( 1.12) 1.00 [ 0.31]( 0.89)
256 1.00 [ 0.00]( 0.42) 1.00 [ -0.49]( 0.91)
512 1.00 [ 0.00]( 0.14) 1.01 [ 0.94]( 0.33)
1024 1.00 [ 0.00]( 0.26) 1.01 [ 0.95]( 0.24)
==================================================================
Test : stream-10
Units : Normalized Bandwidth, MB/s
Interpretation: Higher is better
Statistic : HMean
==================================================================
Test: tip[pct imp](CV) proxy_exec[pct imp](CV)
Copy 1.00 [ 0.00]( 8.37) 0.98 [ -2.35]( 8.36)
Scale 1.00 [ 0.00]( 2.85) 0.93 [ -7.21]( 7.24)
Add 1.00 [ 0.00]( 3.39) 0.93 [ -7.50]( 6.56)
Triad 1.00 [ 0.00]( 6.39) 1.04 [ 4.18]( 7.77)
==================================================================
Test : stream-100
Units : Normalized Bandwidth, MB/s
Interpretation: Higher is better
Statistic : HMean
==================================================================
Test: tip[pct imp](CV) proxy_exec[pct imp](CV)
Copy 1.00 [ 0.00]( 3.91) 1.02 [ 2.00]( 2.92)
Scale 1.00 [ 0.00]( 4.34) 0.99 [ -0.58]( 3.88)
Add 1.00 [ 0.00]( 4.14) 1.02 [ 1.96]( 1.71)
Triad 1.00 [ 0.00]( 1.00) 0.99 [ -0.50]( 2.43)
==================================================================
Test : netperf
Units : Normalized Througput
Interpretation: Higher is better
Statistic : AMean
==================================================================
Clients: tip[pct imp](CV) proxy_exec[pct imp](CV)
1-clients 1.00 [ 0.00]( 0.41) 1.02 [ 2.40]( 0.32)
2-clients 1.00 [ 0.00]( 0.58) 1.02 [ 2.21]( 0.30)
4-clients 1.00 [ 0.00]( 0.35) 1.02 [ 2.20]( 0.63)
8-clients 1.00 [ 0.00]( 0.48) 1.02 [ 1.98]( 0.50)
16-clients 1.00 [ 0.00]( 0.66) 1.02 [ 2.19]( 0.49)
32-clients 1.00 [ 0.00]( 1.15) 1.02 [ 2.17]( 0.75)
64-clients 1.00 [ 0.00]( 1.38) 1.01 [ 1.43]( 1.39)
128-clients 1.00 [ 0.00]( 0.87) 1.01 [ 0.60]( 1.09)
256-clients 1.00 [ 0.00]( 5.36) 1.01 [ 0.54]( 4.29)
512-clients 1.00 [ 0.00](54.39) 0.99 [ -0.61](52.23)
==================================================================
Test : schbench
Units : Normalized 99th percentile latency in us
Interpretation: Lower is better
Statistic : Median
==================================================================
#workers: tip[pct imp](CV) proxy_exec[pct imp](CV)
1 1.00 [ -0.00]( 8.54) 0.76 [ 23.91](23.47)
2 1.00 [ -0.00]( 1.15) 0.90 [ 10.00]( 8.11)
4 1.00 [ -0.00](13.46) 1.10 [-10.42](10.94)
8 1.00 [ -0.00]( 7.14) 0.89 [ 10.53]( 3.92)
16 1.00 [ -0.00]( 3.49) 1.00 [ -0.00]( 8.93)
32 1.00 [ -0.00]( 1.06) 0.96 [ 4.26](10.99)
64 1.00 [ -0.00]( 5.48) 1.08 [ -8.14]( 4.03)
128 1.00 [ -0.00](10.45) 1.09 [ -8.64](13.37)
256 1.00 [ -0.00](31.14) 1.12 [-11.66](16.77)
512 1.00 [ -0.00]( 1.52) 0.98 [ 2.02]( 1.50)
==================================================================
Test : new-schbench-requests-per-second
Units : Normalized Requests per second
Interpretation: Higher is better
Statistic : Median
==================================================================
#workers: tip[pct imp](CV) proxy_exec[pct imp](CV)
1 1.00 [ 0.00]( 1.07) 1.00 [ -0.29]( 0.53)
2 1.00 [ 0.00]( 0.00) 1.00 [ 0.00]( 0.15)
4 1.00 [ 0.00]( 0.00) 1.00 [ -0.29]( 0.30)
8 1.00 [ 0.00]( 0.15) 1.00 [ 0.00]( 0.00)
16 1.00 [ 0.00]( 0.00) 1.00 [ 0.00]( 0.00)
32 1.00 [ 0.00]( 3.41) 1.03 [ 3.50]( 0.27)
64 1.00 [ 0.00]( 1.05) 1.00 [ -0.38]( 4.45)
128 1.00 [ 0.00]( 0.00) 1.00 [ 0.00]( 0.19)
256 1.00 [ 0.00]( 0.72) 0.99 [ -0.61]( 0.63)
512 1.00 [ 0.00]( 0.57) 1.00 [ -0.24]( 0.33)
==================================================================
Test : new-schbench-wakeup-latency
Units : Normalized 99th percentile latency in us
Interpretation: Lower is better
Statistic : Median
==================================================================
#workers: tip[pct imp](CV) proxy_exec[pct imp](CV)
1 1.00 [ -0.00]( 9.11) 0.81 [ 18.75](10.25)
2 1.00 [ -0.00]( 0.00) 0.86 [ 14.29](11.08)
4 1.00 [ -0.00]( 3.78) 1.29 [-28.57](17.25)
8 1.00 [ -0.00]( 0.00) 1.17 [-16.67]( 3.60)
16 1.00 [ -0.00]( 7.56) 1.00 [ -0.00]( 6.88)
32 1.00 [ -0.00](15.11) 0.80 [ 20.00]( 0.00)
64 1.00 [ -0.00]( 9.63) 0.95 [ 5.00]( 7.32)
128 1.00 [ -0.00]( 4.86) 0.96 [ 3.52]( 8.69)
256 1.00 [ -0.00]( 2.34) 0.95 [ 4.70]( 2.78)
512 1.00 [ -0.00]( 0.40) 0.99 [ 0.77]( 0.20)
==================================================================
Test : new-schbench-request-latency
Units : Normalized 99th percentile latency in us
Interpretation: Lower is better
Statistic : Median
==================================================================
#workers: tip[pct imp](CV) proxy_exec[pct imp](CV)
1 1.00 [ -0.00]( 2.73) 1.02 [ -1.82]( 3.15)
2 1.00 [ -0.00]( 0.87) 1.02 [ -2.16]( 1.90)
4 1.00 [ -0.00]( 1.21) 1.04 [ -3.77]( 2.76)
8 1.00 [ -0.00]( 0.27) 1.01 [ -1.31]( 2.01)
16 1.00 [ -0.00]( 4.04) 1.00 [ 0.27]( 0.77)
32 1.00 [ -0.00]( 7.35) 0.89 [ 11.07]( 1.68)
64 1.00 [ -0.00]( 3.54) 1.02 [ -1.55]( 1.47)
128 1.00 [ -0.00]( 0.37) 1.00 [ 0.41]( 0.11)
256 1.00 [ -0.00]( 9.57) 0.91 [ 8.84]( 3.64)
512 1.00 [ -0.00]( 1.82) 1.02 [ -1.93]( 1.21)
==================================================================
Test : Various longer running benchmarks
Units : %diff in throughput reported
Interpretation: Higher is better
Statistic : Median
==================================================================
Benchmarks: %diff
ycsb-cassandra 0.82%
ycsb-mongodb -0.45%
deathstarbench-1x 2.44%
deathstarbench-2x 1.88%
deathstarbench-3x 0.09%
deathstarbench-6x 1.94%
hammerdb+mysql 16VU 3.65%
hammerdb+mysql 64VU -0.59%
>
> As I’m trying to submit this work in smallish digestible pieces,
> in this series, I’m only submitting for review the logic that
> allows us to do the proxying if the lock owner is on the same
> runqueue as the blocked waiter: Introducing the
> CONFIG_SCHED_PROXY_EXEC option and boot-argument, reworking the
> task_struct::blocked_on pointer and wrapper functions, the
> initial sketch of the find_proxy_task() logic, some fixes for
> using split contexts, and finally same-runqueue proxying.
>
> As I mentioned above, for the series I’m submitting here, it has
> only barely changed from v17. With the main difference being
> slightly different order of checks for cases where we don’t
> actually do anything yet (more on why below), and use of
> READ_ONCE for the on_rq reads to avoid the compiler fusing
> loads, which I was bitten by with the full series.
For this series (Single RunQueue Proxy), feel free to include:
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
I'll go and test the full series next and reply with the
results on this same thread sometime next week. Meanwhile I'll
try to queue a longer locktorture run over the weekend. I'll
let you know if I see anything out of the ordinary on my setup.
--
Thanks and Regards,
Prateek
prev parent reply other threads:[~2025-06-27 3:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-25 20:30 John Stultz
2025-06-25 20:30 ` [PATCH v18 1/8] sched: Add CONFIG_SCHED_PROXY_EXEC & boot argument to enable/disable John Stultz
2025-06-25 20:30 ` [PATCH v18 2/8] locking/mutex: Rework task_struct::blocked_on John Stultz
2025-06-25 20:30 ` [PATCH v18 3/8] locking/mutex: Add p->blocked_on wrappers for correctness checks John Stultz
2025-06-25 20:30 ` [PATCH v18 4/8] sched: Move update_curr_task logic into update_curr_se John Stultz
2025-06-25 20:30 ` [PATCH v18 5/8] sched: Fix runtime accounting w/ split exec & sched contexts John Stultz
2025-06-25 20:30 ` [PATCH v18 6/8] sched: Add an initial sketch of the find_proxy_task() function John Stultz
2025-06-25 20:31 ` [PATCH v18 7/8] sched: Fix proxy/current (push,pull)ability John Stultz
2025-06-25 20:31 ` [PATCH v18 8/8] sched: Start blocked_on chain processing in find_proxy_task() John Stultz
2025-06-27 3:04 ` K Prateek Nayak [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=a8de5df6-665d-4c97-aff9-854ccc49adfc@amd.com \
--to=kprateek.nayak@amd.com \
--cc=Metin.Kaya@arm.com \
--cc=boqun.feng@gmail.com \
--cc=bsegall@google.com \
--cc=daniel.lezcano@linaro.org \
--cc=dietmar.eggemann@arm.com \
--cc=hupu.gm@gmail.com \
--cc=joelagnelf@nvidia.com \
--cc=jstultz@google.com \
--cc=juri.lelli@redhat.com \
--cc=kernel-team@android.com \
--cc=kuyo.chang@mediatek.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=qyousef@layalina.io \
--cc=rostedt@goodmis.org \
--cc=suleiman@google.com \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=will@kernel.org \
--cc=xuewen.yan94@gmail.com \
--cc=zezeozue@google.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
all inboxes | Powered by JetHome®