From: Libo Chen <libo.chen@oracle.com>
To: K Prateek Nayak <kprateek.nayak@amd.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Chen Yu <yu.c.chen@intel.com>,
linux-kernel@vger.kernel.org
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
David Vernet <void@manifault.com>,
"Gautham R. Shenoy" <gautham.shenoy@amd.com>,
Swapnil Sapkal <swapnil.sapkal@amd.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>
Subject: Re: [RFC PATCH 0/8] sched/fair: Propagate load balancing stats up the sched domain hierarchy
Date: Fri, 21 Mar 2025 03:04:31 -0700 [thread overview]
Message-ID: <9af4bb66-83c4-4257-bfc3-dbcb2185a7e6@oracle.com> (raw)
In-Reply-To: <20250313093746.6760-1-kprateek.nayak@amd.com>
On 3/13/25 02:37, K Prateek Nayak wrote:
> Benchmark results
> =================
>
Hi Prateek,
Definitely like the idea, esp. if we can pull this off on newidle lb
which tends to be more problematic on systems with a large number
of cores. But the data below on periodic lb isn't I guess as good as
I expect. So I am wondering if the cost of update_[sd|sg]_lb_stats()
actually went down as the result of the caching?
Thanks,
Libo
> ==================================================================
> Test : hackbench
> Units : Normalized time in seconds
> Interpretation: Lower is better
> Statistic : AMean
> ==================================================================
> Case: tip[pct imp](CV) stats_prop[pct imp](CV)
> 1-groups 1.00 [ -0.00](10.12) 1.09 [ -9.11](11.93)
> 2-groups 1.00 [ -0.00]( 6.92) 1.00 [ -0.22]( 4.57)
> 4-groups 1.00 [ -0.00]( 3.14) 0.99 [ 0.83]( 1.77)
> 8-groups 1.00 [ -0.00]( 1.35) 1.00 [ -0.31]( 2.24)
> 16-groups 1.00 [ -0.00]( 1.32) 0.99 [ 0.84]( 0.67)
>
>
> ==================================================================
> Test : tbench
> Units : Normalized throughput
> Interpretation: Higher is better
> Statistic : AMean
> ==================================================================
> Clients: tip[pct imp](CV) stats_prop[pct imp](CV)
> 1 1.00 [ 0.00]( 0.43) 0.99 [ -0.87]( 1.34)
> 2 1.00 [ 0.00]( 0.58) 1.02 [ 2.14]( 0.29)
> 4 1.00 [ 0.00]( 0.54) 1.01 [ 1.24]( 0.82)
> 8 1.00 [ 0.00]( 0.49) 1.01 [ 0.62]( 0.97)
> 16 1.00 [ 0.00]( 1.06) 1.01 [ 0.94]( 0.70)
> 32 1.00 [ 0.00]( 1.27) 0.99 [ -1.24]( 1.38)
> 64 1.00 [ 0.00]( 1.54) 1.00 [ -0.43]( 0.36)
> 128 1.00 [ 0.00]( 0.38) 1.00 [ -0.01]( 1.22)
> 256 1.00 [ 0.00]( 1.85) 1.02 [ 1.58]( 0.90)
> 512 1.00 [ 0.00]( 0.31) 1.01 [ 0.76]( 1.19)
> 1024 1.00 [ 0.00]( 0.19) 1.00 [ 0.44]( 0.35)
>
>
> ==================================================================
> Test : stream-10
> Units : Normalized Bandwidth, MB/s
> Interpretation: Higher is better
> Statistic : HMean
> ==================================================================
> Test: tip[pct imp](CV) stats_prop[pct imp](CV)
> Copy 1.00 [ 0.00](11.31) 1.02 [ 1.69]( 6.44)
> Scale 1.00 [ 0.00]( 6.62) 1.01 [ 0.80]( 5.37)
> Add 1.00 [ 0.00]( 7.06) 1.02 [ 1.54]( 6.72)
> Triad 1.00 [ 0.00]( 8.91) 1.01 [ 1.36]( 6.73)
>
>
> ==================================================================
> Test : stream-100
> Units : Normalized Bandwidth, MB/s
> Interpretation: Higher is better
> Statistic : HMean
> ==================================================================
> Test: tip[pct imp](CV) stats_prop[pct imp](CV)
> Copy 1.00 [ 0.00]( 2.01) 0.98 [ -1.55]( 2.15)
> Scale 1.00 [ 0.00]( 1.49) 1.00 [ 0.23]( 0.58)
> Add 1.00 [ 0.00]( 2.67) 1.01 [ 0.65]( 1.95)
> Triad 1.00 [ 0.00]( 2.19) 1.01 [ 0.61]( 1.37)
>
>
> ==================================================================
> Test : netperf
> Units : Normalized Througput
> Interpretation: Higher is better
> Statistic : AMean
> ==================================================================
> Clients: tip[pct imp](CV) stats_prop[pct imp](CV)
> 1-clients 1.00 [ 0.00]( 1.43) 1.00 [ 0.17]( 0.32)
> 2-clients 1.00 [ 0.00]( 1.02) 1.01 [ 1.00]( 0.44)
> 4-clients 1.00 [ 0.00]( 0.83) 1.01 [ 0.62]( 0.36)
> 8-clients 1.00 [ 0.00]( 0.73) 1.00 [ -0.11]( 0.65)
> 16-clients 1.00 [ 0.00]( 0.97) 1.00 [ 0.49]( 0.77)
> 32-clients 1.00 [ 0.00]( 0.88) 1.00 [ 0.30]( 0.94)
> 64-clients 1.00 [ 0.00]( 1.49) 1.00 [ 0.36]( 1.57)
> 128-clients 1.00 [ 0.00]( 1.05) 1.00 [ 0.14]( 1.46)
> 256-clients 1.00 [ 0.00]( 3.85) 1.00 [ -0.04]( 4.85)
> 512-clients 1.00 [ 0.00](59.63) 1.00 [ -0.02](62.28)
>
>
> ==================================================================
> Test : schbench
> Units : Normalized 99th percentile latency in us
> Interpretation: Lower is better
> Statistic : Median
> ==================================================================
> #workers: tip[pct imp](CV) stats_prop[pct imp](CV)
> 1 1.00 [ -0.00]( 6.67) 0.76 [ 24.44](35.80)
> 2 1.00 [ -0.00](10.18) 0.87 [ 13.04](10.38)
> 4 1.00 [ -0.00]( 4.49) 1.04 [ -4.26]( 3.14)
> 8 1.00 [ -0.00]( 6.68) 0.98 [ 1.89]( 8.07)
> 16 1.00 [ -0.00]( 1.87) 1.03 [ -3.28]( 5.21)
> 32 1.00 [ -0.00]( 4.01) 0.98 [ 2.20]( 1.31)
> 64 1.00 [ -0.00]( 3.21) 1.00 [ -0.00]( 3.23)
> 128 1.00 [ -0.00](44.13) 1.06 [ -6.43](113.66)
> 256 1.00 [ -0.00](14.46) 1.04 [ -3.52]( 8.43)
> 512 1.00 [ -0.00]( 1.95) 1.02 [ -1.80]( 1.14)
>
>
> ==================================================================
> Test : new-schbench-requests-per-second
> Units : Normalized Requests per second
> Interpretation: Higher is better
> Statistic : Median
> ==================================================================
> #workers: tip[pct imp](CV) stats_prop[pct imp](CV)
> 1 1.00 [ 0.00]( 0.46) 1.00 [ 0.00]( 0.55)
> 2 1.00 [ 0.00]( 0.15) 0.99 [ -0.88]( 0.26)
> 4 1.00 [ 0.00]( 0.15) 0.99 [ -0.59]( 0.15)
> 8 1.00 [ 0.00]( 0.15) 0.99 [ -0.88]( 0.26)
> 16 1.00 [ 0.00]( 0.00) 1.00 [ -0.29]( 0.15)
> 32 1.00 [ 0.00]( 3.40) 1.07 [ 6.59]( 0.16)
> 64 1.00 [ 0.00]( 7.09) 1.00 [ -0.38]( 0.96)
> 128 1.00 [ 0.00]( 0.00) 1.00 [ 0.00]( 0.20)
> 256 1.00 [ 0.00]( 1.12) 1.00 [ -0.30]( 1.50)
> 512 1.00 [ 0.00]( 0.22) 1.05 [ 4.86]( 0.71)
>
>
> ==================================================================
> Test : new-schbench-wakeup-latency
> Units : Normalized 99th percentile latency in us
> Interpretation: Lower is better
> Statistic : Median
> ==================================================================
> #workers: tip[pct imp](CV) stats_prop[pct imp](CV)
> 1 1.00 [ -0.00](19.72) 0.85 [ 15.38](16.75)
> 2 1.00 [ -0.00](15.96) 1.00 [ -0.00]( 0.00)
> 4 1.00 [ -0.00]( 3.87) 1.00 [ -0.00]( 4.08)
> 8 1.00 [ -0.00]( 8.15) 1.00 [ -0.00](11.71)
> 16 1.00 [ -0.00]( 3.87) 0.92 [ 7.69]( 4.19)
> 32 1.00 [ -0.00](12.99) 0.73 [ 26.67]( 0.00)
> 64 1.00 [ -0.00]( 6.20) 1.12 [-12.50]( 9.94)
> 128 1.00 [ -0.00]( 0.96) 0.98 [ 1.55]( 0.95)
> 256 1.00 [ -0.00]( 2.76) 0.99 [ 1.45]( 1.38)
> 512 1.00 [ -0.00]( 0.20) 1.20 [-20.42]( 0.00)
>
>
> ==================================================================
> Test : new-schbench-request-latency
> Units : Normalized 99th percentile latency in us
> Interpretation: Lower is better
> Statistic : Median
> ==================================================================
> #workers: tip[pct imp](CV) stats_prop[pct imp](CV)
> 1 1.00 [ -0.00]( 1.07) 1.02 [ -2.08]( 0.13)
> 2 1.00 [ -0.00]( 0.14) 1.04 [ -3.97]( 0.13)
> 4 1.00 [ -0.00]( 1.39) 1.03 [ -3.15]( 0.13)
> 8 1.00 [ -0.00]( 0.36) 1.03 [ -3.16]( 0.00)
> 16 1.00 [ -0.00]( 1.18) 1.02 [ -1.59]( 0.75)
> 32 1.00 [ -0.00]( 8.42) 0.81 [ 19.08]( 0.25)
> 64 1.00 [ -0.00]( 4.85) 1.01 [ -1.10]( 2.58)
> 128 1.00 [ -0.00]( 0.28) 1.00 [ -0.21]( 0.38)
> 256 1.00 [ -0.00](10.52) 0.95 [ 4.74]( 6.94)
> 512 1.00 [ -0.00]( 0.69) 1.09 [ -8.99]( 0.27)
>
>
> ==================================================================
> Test : Various longer running benchmarks
> Units : %diff in throughput reported
> Interpretation: Higher is better
> Statistic : Median
> ==================================================================
> Benchmarks: %diff
>
> ycsb-cassandra -0.54%
> ycsb-mongodb 0.09%
>
> deathstarbench-1x -0.30%
> deathstarbench-2x 2.38%
> deathstarbench-3x 0.58%
> deathstarbench-6x 0.62%
>
> hammerdb+mysql 16VU 0.76%
> hammerdb+mysql 64VU 0.74%
> ---
>
next prev parent reply other threads:[~2025-03-21 10:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-13 9:37 K Prateek Nayak
2025-03-13 9:37 ` [RFC PATCH 1/8] sched/topology: Assign sd_share for all non NUMA sched domains K Prateek Nayak
2025-03-13 9:37 ` [RFC PATCH 2/8] sched/topology: Introduce sg->shared K Prateek Nayak
2025-03-13 9:37 ` [RFC PATCH 3/8] sched/fair: Move "struct sg_lb_stats" and its dependencies to sched.h K Prateek Nayak
2025-03-13 9:37 ` [RFC PATCH 4/8] sched/fair: Move sg_{overloaded,overutilized} calculation to sg_lb_stats K Prateek Nayak
2025-03-13 9:37 ` [RFC PATCH 5/8] sched/topology: Define sg_lb_stats_prop and embed it inside sched_domain_shared K Prateek Nayak
2025-03-13 9:37 ` [RFC PATCH 6/8] sched/fair: Increase probability of lb stats being reused K Prateek Nayak
2025-03-17 18:07 ` Chen, Yu C
2025-03-19 6:51 ` K Prateek Nayak
2025-03-13 9:37 ` [RFC PATCH 7/8] sched/fair: Retrieve cached group stats from sg_lb_stats_prop K Prateek Nayak
2025-03-17 18:04 ` Chen, Yu C
2025-03-19 6:42 ` K Prateek Nayak
2025-03-13 9:37 ` [RFC PATCH 8/8] sched/fair: Update stats for sched_domain using the sched_group stats K Prateek Nayak
2025-03-16 10:29 ` [RFC PATCH 09/08] [ANNOTATE] sched/fair: Stats versioning and invalidation K Prateek Nayak
2025-03-16 10:29 ` [RFC PATCH 10/08] sched/fair: Compute nr_{numa,preferred}_running for non-NUMA domains K Prateek Nayak
2025-03-16 10:29 ` [RFC PATCH 11/08] sched/fair: Move from "last_update" to stats versioning K Prateek Nayak
2025-03-16 10:29 ` [RFC PATCH 12/08] sched/fair: Record the cpu that updated the stats last K Prateek Nayak
2025-03-16 10:29 ` [RFC PATCH 13/08] sched/fair: Invalidate stats once the load balancing instance is done K Prateek Nayak
2025-03-16 10:29 ` [RFC PATCH 14/08] [DEBUG] sched/fair: Add more lb_stats around lb_time and stats reuse K Prateek Nayak
2025-03-16 10:29 ` [RFC PATCH 15/08] [DEBUG] tools/lib/perf: Extend schedstats v17 headers to include the new debug fields K Prateek Nayak
2025-03-17 17:25 ` [RFC PATCH 0/8] sched/fair: Propagate load balancing stats up the sched domain hierarchy Peter Zijlstra
2025-03-17 18:23 ` Chen, Yu C
2025-03-21 10:04 ` Libo Chen [this message]
2025-03-24 3:58 ` K Prateek Nayak
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=9af4bb66-83c4-4257-bfc3-dbcb2185a7e6@oracle.com \
--to=libo.chen@oracle.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=gautham.shenoy@amd.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sshegde@linux.ibm.com \
--cc=swapnil.sapkal@amd.com \
--cc=vincent.guittot@linaro.org \
--cc=void@manifault.com \
--cc=vschneid@redhat.com \
--cc=yu.c.chen@intel.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®