linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Larabel <Michael@phoronix.com>
To: Giovanni Gherdovich <ggherdovich@suse.cz>,
	Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>
Cc: Jon Grimm <Jon.Grimm@amd.com>,
	Nathan Fontenot <Nathan.Fontenot@amd.com>,
	Yazen Ghannam <Yazen.Ghannam@amd.com>,
	Thomas Lendacky <Thomas.Lendacky@amd.com>,
	Suthikulpanit Suravee <Suravee.Suthikulpanit@amd.com>,
	Mel Gorman <mgorman@techsingularity.net>, Pu Wen <puwen@hygon.cn>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	x86@kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH v2 0/1] AMD EPYC: fix schedutil perf regression (freq-invariance)
Date: Sun, 24 Jan 2021 16:30:57 -0600	[thread overview]
Message-ID: <a5071cb5-6a5b-d2e4-ff06-fa7810b8127c@phoronix.com> (raw)
In-Reply-To: <20210122204038.3238-1-ggherdovich@suse.cz>

 From ongoing tests of this patch, it still certainly shows to address 
most of the Linux 5.11 performance regression previously encountered 
when using Schedutil. Additionally, for a number of workloads where not 
seeing a regression from 5.10 to 5.11 Git is still showing even better 
performance with this patch. The power monitoring on the AMD EPYC server 
is showing higher power spikes but the average power consumption rate is 
roughly comparable to that of Linux 5.11 Git, which is higher than 5.10 
by just about 3%.

So this patch still seems to be working out well and indeed taking care 
of some wide losses seen otherwise on Linux 5.11 when using Schedutil on 
AMD Zen2/Zen3. Still have some other tests running but so far no 
unexpected results.

Michael


AMD EPYC 7F72 2P

On an EPYC 7F72 2P server[1] across 147 test cases I am finding the 
patched Linux 5.11 kernel to be just over 1% faster than 5.10 stable 
compared to the unpatched 5.11 Git being just behind 5.10. For the 
workloads on that server where Linux 5.11 is slower with Schedutil, the 
patch indeed is largely addressing that regression and also providing 
other improvements.

During that testing, the amd_energy interface was monitored. Linux 5.11 
with Schedutil AMD freq invariance did show on average 10 Watts (~3.7%) 
higher power consumption on average than Linux 5.10 with Schedutil. But 
with this patch, that average is still basically the same. The peak 
power consumption during any of the tests was higher at 530~549 Watts 
compared to 501 Watts with Linux 5.10. Overall the performance is 
looking good but given amd_energy still not working for consumer models, 
I don't have much power data to share at the moment.

Ryzen 9 5950X

Expanding on the prior testing with the 5950X, I ran some follow-up 
tests[2]. Of 221 test cases there, the current Linux 5.11 Git 
performance came around 2% slower on a geo mean basis than Linux 5.10 
while the patched performance pulls it to ~2.5% faster than 5.10. There 
still are some cases where Linux 5.10 is faster, but overall at least 
the patched Linux 5.11 performance doesn't show nearly as many 
regressions. In a number of test cases, the Linux 5.11 patched 
performance is outright better than Linux 5.10 even where 5.11 
(un-patched) hadn't regressed or by that much.

Ryzen 5 4500U

For something at the lower end of the spectrum I also ran a number of 
tests on a Ryzen 5 4500U notebook[3]. Linux 5.11 (unpatched) doesn't see 
as many regressions as on the larger systems but still the patched 
performance did help in a number of tests, particularly around 
graphics/gaming. In the heavier multi-core core tests are still a number 
of cases where Linux 5.10 is faster than patched/unpatched 5.11. The 
patched kernel in those 90 tests came out to being about 4% faster than 
5.10.

(Result highlights below, results with little change set to hidden by 
default.)
[1] 
https://openbenchmarking.org/result/2101248-HA-AMDEPYC7F52&grs&hlc=1&hnr=1&hlc=1
[2] https://openbenchmarking.org/result/2101242-HA-RYZEN959530&grs&hlc=1
[3] 
https://openbenchmarking.org/result/2101232-PTS-RENOIRLI89&grs&hnr=1&hlc=1


On 1/22/21 2:40 PM, Giovanni Gherdovich wrote:
> Michael Larabel from Phoronix.com graciously tested v1, see results at:
>
> AMD EPYC 7702 -
> https://openbenchmarking.org/result/2101210-PTS-LINUX51178
>
> AMD Ryzen 9 5950X -
> https://openbenchmarking.org/result/2101212-HA-RYZEN959566
>
> The reported regression is recovered, and some workloads even report an
> improvement over the v5.10 results.
>
> Thanks Michael for the feedback!
>
>
> v1 at https://lore.kernel.org/lkml/20210121003223.20257-1-ggherdovich@suse.cz/
>
> Changes wrt v1:
>
> - move code around so that it builds for non-x86 architectures too
>
> Giovanni Gherdovich (1):
>    x86,sched: On AMD EPYC set freq_max = max_boost in schedutil invariant
>      formula
>
>   drivers/cpufreq/acpi-cpufreq.c   | 64 +++++++++++++++++++++++++++++++-
>   drivers/cpufreq/cpufreq.c        |  3 ++
>   include/linux/cpufreq.h          |  5 +++
>   kernel/sched/cpufreq_schedutil.c |  8 +++-
>   4 files changed, 76 insertions(+), 4 deletions(-)
>

  parent reply	other threads:[~2021-01-24 22:50 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-22 20:40 [PATCH v2 0/1] AMD EPYC: fix schedutil perf regression (freq-invariance) Giovanni Gherdovich
2021-01-22 20:40 ` [PATCH v2 1/1] x86,sched: On AMD EPYC set freq_max = max_boost in schedutil invariant formula Giovanni Gherdovich
2021-01-25 10:04   ` Peter Zijlstra
2021-01-26  9:28     ` Giovanni Gherdovich
2021-01-26 10:02       ` Peter Zijlstra
2021-02-02 18:45       ` Rafael J. Wysocki
2021-02-02 19:11         ` Rafael J. Wysocki
2021-02-03  9:56           ` Giovanni Gherdovich
2021-02-02 18:40     ` Rafael J. Wysocki
2021-01-25 10:06   ` Peter Zijlstra
2021-01-26  9:09     ` Giovanni Gherdovich
2021-01-26  9:31       ` Mel Gorman
2021-01-26 10:05         ` Peter Zijlstra
     [not found]           ` <1611933781.15858.48.camel@suse.cz>
2021-02-02 14:17             ` Giovanni Gherdovich
2021-02-02 18:21               ` Peter Zijlstra
2021-02-02 18:29                 ` Rafael J. Wysocki
2021-02-02 19:00                   ` Rafael J. Wysocki
2021-02-02 18:59   ` Rafael J. Wysocki
2021-02-02 19:26     ` Rafael J. Wysocki
2021-02-03  8:39       ` Giovanni Gherdovich
2021-02-03 13:40         ` Rafael J. Wysocki
2021-02-03  9:12     ` Giovanni Gherdovich
2021-02-03  6:04   ` Viresh Kumar
2021-01-24 22:30 ` Michael Larabel [this message]
2021-01-25  8:34   ` [PATCH v2 0/1] AMD EPYC: fix schedutil perf regression (freq-invariance) Peter Zijlstra
2021-01-26  9:01     ` Giovanni Gherdovich

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=a5071cb5-6a5b-d2e4-ff06-fa7810b8127c@phoronix.com \
    --to=michael@phoronix.com \
    --cc=Jon.Grimm@amd.com \
    --cc=Nathan.Fontenot@amd.com \
    --cc=Suravee.Suthikulpanit@amd.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=Yazen.Ghannam@amd.com \
    --cc=bp@alien8.de \
    --cc=dietmar.eggemann@arm.com \
    --cc=ggherdovich@suse.cz \
    --cc=juri.lelli@redhat.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=puwen@hygon.cn \
    --cc=rjw@rjwysocki.net \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=x86@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).