From: Abel Wu <wuyun.abel@bytedance.com>
To: K Prateek Nayak <kprateek.nayak@amd.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>, Mel Gorman <mgorman@suse.de>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Valentin Schneider <valentin.schneider@arm.com>
Cc: Josh Don <joshdon@google.com>, Chen Yu <yu.c.chen@intel.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
"Gautham R . Shenoy" <gautham.shenoy@amd.com>,
Aubrey Li <aubrey.li@intel.com>,
Qais Yousef <qais.yousef@arm.com>,
Juri Lelli <juri.lelli@redhat.com>,
Rik van Riel <riel@surriel.com>,
Yicong Yang <yangyicong@huawei.com>,
Barry Song <21cnbao@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 0/4] sched/fair: Improve scan efficiency of SIS
Date: Thu, 24 Nov 2022 11:50:13 +0800 [thread overview]
Message-ID: <02890ec6-b7dc-e0cd-4797-d5343d42361c@bytedance.com> (raw)
In-Reply-To: <b8eb593a-cde9-bb23-2092-6b563ce814c8@amd.com>
Hi Prateek, thanks again for your detailed test!
On 11/22/22 7:28 PM, K Prateek Nayak wrote:
> Hello Abel,
>
> Following are the results for hackbench with larger number of
> groups, ycsb-mongodb, Spec-JBB, and unixbench. Apart for
> a regression in unixbench spawn in NPS2 and NPS4 mode and
> unixbench syscall in NPs2 mode, everything looks good.
>
> ...
>
> -> unixbench-syscall
>
> o NPS4
>
> kernel: tip sis_core
> Min unixbench-syscall-1 2971799.80 ( 0.00%) 2979335.60 ( -0.25%)
> Min unixbench-syscall-512 7824196.90 ( 0.00%) 8155610.20 ( -4.24%)
> Amean unixbench-syscall-1 2973045.43 ( 0.00%) 2982036.13 * -0.30%*
> Amean unixbench-syscall-512 7826302.17 ( 0.00%) 8173026.57 * -4.43%* <-- Regression in syscall for larger worker count
> CoeffVar unixbench-syscall-1 0.04 ( 0.00%) 0.09 (-139.63%)
> CoeffVar unixbench-syscall-512 0.03 ( 0.00%) 0.20 (-701.13%)
>
>
> -> unixbench-spawn
>
> o NPS1
>
> kernel: tip sis_core
> Min unixbench-spawn-1 6536.50 ( 0.00%) 6000.30 ( -8.20%)
> Min unixbench-spawn-512 72571.40 ( 0.00%) 70829.60 ( -2.40%)
> Hmean unixbench-spawn-1 6811.16 ( 0.00%) 7016.11 ( 3.01%)
> Hmean unixbench-spawn-512 72801.77 ( 0.00%) 71012.03 * -2.46%*
> CoeffVar unixbench-spawn-1 3.69 ( 0.00%) 13.52 (-266.69%)
> CoeffVar unixbench-spawn-512 0.27 ( 0.00%) 0.22 ( 18.25%)
>
> o NPS2
>
> kernel: tip sis_core
> Min unixbench-spawn-1 7042.20 ( 0.00%) 7078.70 ( 0.52%)
> Min unixbench-spawn-512 85571.60 ( 0.00%) 77362.60 ( -9.59%)
> Hmean unixbench-spawn-1 7199.01 ( 0.00%) 7276.55 ( 1.08%)
> Hmean unixbench-spawn-512 85717.77 ( 0.00%) 77923.73 * -9.09%* <-- Regression in spawn test for larger worker count
> CoeffVar unixbench-spawn-1 3.50 ( 0.00%) 3.30 ( 5.70%)
> CoeffVar unixbench-spawn-512 0.20 ( 0.00%) 0.82 (-304.88%)
>
> o NPS4
>
> kernel: tip sis_core
> Min unixbench-spawn-1 7521.90 ( 0.00%) 8102.80 ( 7.72%)
> Min unixbench-spawn-512 84245.70 ( 0.00%) 73074.50 ( -13.26%)
> Hmean unixbench-spawn-1 7659.12 ( 0.00%) 8645.19 * 12.87%*
> Hmean unixbench-spawn-512 84908.77 ( 0.00%) 73409.49 * -13.54%* <-- Regression in spawn test for larger worker count
> CoeffVar unixbench-spawn-1 1.92 ( 0.00%) 5.78 (-200.56%)
> CoeffVar unixbench-spawn-512 0.76 ( 0.00%) 0.41 ( 46.58%)
>
> ...
>
> For unixbench regressions, I do not see anything obvious jump up
> in perf traces captureed with IBS. top shows over 99% utilization
> which would ideally mean there are not many updates to the mask.
> I'll take some more look at the spawn test case and get back to you.
These regressions seems to be common in full parallel tests. I
guess it might be due to over updating the idle cpumask when LLC
is overloaded which is not necessary if SIS_UTIL enabled, but I
need to dig it further. Maybe the rq avg_idle or nr_idle_scan need
to be taken into consideration as well. Thanks for providing these
important information.
>
> ~~~~~~~~~~~~~
> ~ Hackbench ~
> ~~~~~~~~~~~~~
>
> $ perf bench sched messaging -p -l 50000 -g <groups>
>
> o NPS1
>
> kernel: tip sis_core
> 32-groups: 6.20 (0.00 pct) 5.86 (5.48 pct)
> 64-groups: 16.55 (0.00 pct) 15.21 (8.09 pct)
> 128-groups: 42.57 (0.00 pct) 34.63 (18.65 pct)
> 256-groups: 71.69 (0.00 pct) 67.11 (6.38 pct)
> 512-groups: 108.48 (0.00 pct) 110.23 (-1.61 pct)
>
> o NPS2
>
> kernel: tip sis_core
> 32-groups: 6.56 (0.00 pct) 5.60 (14.63 pct)
> 64-groups: 15.74 (0.00 pct) 14.45 (8.19 pct)
> 128-groups: 39.93 (0.00 pct) 35.33 (11.52 pct)
> 256-groups: 74.49 (0.00 pct) 69.65 (6.49 pct)
> 512-groups: 112.22 (0.00 pct) 113.75 (-1.36 pct)
>
> o NPS4:
>
> kernel: tip sis_core
> 32-groups: 9.48 (0.00 pct) 5.64 (40.50 pct)
> 64-groups: 15.38 (0.00 pct) 14.13 (8.12 pct)
> 128-groups: 39.93 (0.00 pct) 34.47 (13.67 pct)
> 256-groups: 75.31 (0.00 pct) 67.98 (9.73 pct)
> 512-groups: 115.37 (0.00 pct) 111.15 (3.65 pct)
>
> Note: Hackbench with 32-groups show run to run variation
> on tip but is more stable with sis_core. Hackbench for
> 64-groups and beyond is stable on both kernels.
>
The result is consistent with mine except 512-groups which I
didn't test. The 512-groups test may have the same problem
aforementioned.
Thanks & Regards,
Abel
next prev parent reply other threads:[~2022-11-24 3:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-19 12:28 Abel Wu
2022-10-19 12:28 ` [PATCH v6 1/4] sched/fair: Skip core update if task pending Abel Wu
2022-10-19 12:28 ` [PATCH v6 2/4] sched/fair: Ignore SIS_UTIL when has_idle_core Abel Wu
2022-10-19 12:28 ` [PATCH v6 3/4] sched/fair: Introduce SIS_CORE Abel Wu
2022-10-21 4:03 ` Chen Yu
2022-10-21 4:30 ` Abel Wu
2022-10-21 4:34 ` Chen Yu
2022-10-21 9:35 ` Abel Wu
2022-10-21 11:14 ` Chen Yu
2022-10-19 12:28 ` [PATCH v6 4/4] sched/fair: Deal with SIS scan failures Abel Wu
2022-11-04 7:29 ` [PATCH v6 0/4] sched/fair: Improve scan efficiency of SIS Abel Wu
2022-11-14 5:45 ` K Prateek Nayak
2022-11-15 8:31 ` Abel Wu
2022-11-15 11:28 ` K Prateek Nayak
2022-11-22 11:28 ` K Prateek Nayak
2022-11-24 3:50 ` Abel Wu [this message]
2023-02-07 3:42 ` K Prateek Nayak
2023-02-16 13:18 ` Abel Wu
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=02890ec6-b7dc-e0cd-4797-d5343d42361c@bytedance.com \
--to=wuyun.abel@bytedance.com \
--cc=21cnbao@gmail.com \
--cc=aubrey.li@intel.com \
--cc=dietmar.eggemann@arm.com \
--cc=gautham.shenoy@amd.com \
--cc=joshdon@google.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=riel@surriel.com \
--cc=tim.c.chen@linux.intel.com \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.org \
--cc=yangyicong@huawei.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®