archive mirror
 help / color / mirror / Atom feed
From: Michael Larabel <>
To: "Rafael J. Wysocki" <>
Cc: "Rafael J. Wysocki" <>,
	Giovanni Gherdovich <>,
	Borislav Petkov <>, Ingo Molnar <>,
	Peter Zijlstra <>,
	Viresh Kumar <>,
	Jon Grimm <>,
	Nathan Fontenot <>,
	Yazen Ghannam <>,
	Thomas Lendacky <>,
	Suthikulpanit Suravee <>,
	Mel Gorman <>, Pu Wen <>,
	Juri Lelli <>,
	Vincent Guittot <>,
	Dietmar Eggemann <>,
	the arch/x86 maintainers <>,
	Linux PM <>,
	Linux Kernel Mailing List <>,
	ACPI Devel Maling List <>
Subject: Re: [PATCH v3 1/1] x86,sched: On AMD EPYC set freq_max = max_boost in schedutil invariant formula
Date: Thu, 4 Feb 2021 17:04:23 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2/4/21 7:40 AM, Rafael J. Wysocki wrote:
> On Thu, Feb 4, 2021 at 12:36 AM Michael Larabel <> wrote:
>> On 2/3/21 12:25 PM, Rafael J. Wysocki wrote:
>>> On Wednesday, February 3, 2021 3:11:37 PM CET Rafael J. Wysocki wrote:
>>>> On Wed, Feb 3, 2021 at 2:53 PM Giovanni Gherdovich <> wrote:
>>>> [cut]
>>>>> Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems")
>>>>> Fixes: 976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for frequency invariance on AMD EPYC")
>>>>> Reported-by: Michael Larabel <>
>>>>> Tested-by: Michael Larabel <>
>>>>> Signed-off-by: Giovanni Gherdovich <>
>>>>> ---
>>>>>    drivers/cpufreq/acpi-cpufreq.c   | 61 ++++++++++++++++++++++++++++++--
>>>>>    drivers/cpufreq/cpufreq.c        |  3 ++
>>>>>    include/linux/cpufreq.h          |  5 +++
>>>>>    kernel/sched/cpufreq_schedutil.c |  8 +++--
>>>> I don't really think that it is necessary to modify schedutil to
>>>> address this issue.
>>> So below is a prototype of an alternative fix for the issue at hand.
>>> I can't really test it here, because there's no _CPC in the ACPI tables of my
>>> test machines, so testing it would be appreciated.  However, AFAICS these
>>> machines are affected by the performance issue related to the scale-invariance
>>> when they are running acpi-cpufreq, so what we are doing here is not entirely
>>> sufficient.
>> I have benchmarks running on several Ryzen and EPYC systems with this
>> patch. The full batch of tests won't be done until tomorrow, but in
>> looking at the data so far from an AMD EPYC 7F72 2P server over the past
>> few hours, this patch does provide fairly comparable numbers to
>> Giovanni's patch. There were a few outliers so far but waiting to see
>> with the complete set of results. At the very least it's clear enough
>> already this new patch is at least an improvement over the current 5.11
>> upstream state with schedutil on AMD.
> Thanks for the feedback, much appreciated!
> Let me submit the patch properly, then.

Everything continues looking good in running this patch on a variety of 
AMD Zen2/Zen3 systems.

As Giovanni has been focusing on EPYC testing, I have been running 
several Ryzen laptops/desktop for more exposure and there it's looking 
very good. On a Ryzen 9 5900X[1] when looking at this latest patch 
against current 5.11 Git and 5.10, the performance is recovered and in 
some cases better off now than 5.10 with Schedutil. No anomalies there 
and with other Zen 2/3 desktops and Zen 2 notebook the performance 
relative to 5.10 is comparable or in some cases better while all 
indications point to the 5.11 regression being addressed. Some of the 
slower systems still finishing up but no unexpected results yet and 
likely just redundant testing at this point.

Tests on EPYC hardware has also been looking good. With some 44 tests on 
an EPYC 7F72 2P setup[2] when taking the geometric mean of all the data 
finding it rightly in line with the prior patch from Giovanni. EPYC 7702 
and EPYC 7F52 1P performance similarly showing no regression any longer 
with the patched kernel. This patch also seemed to help CPUFreq ondemand 
performance improve as well in some cases.

Will advise if hitting anything unexpected with the remainder of the 
testing but all is looking solid at this point and a definite 
improvement over the current 5.11 Git state.

Tested-by: Michael Larabel <>

[1] (5.10 
stable vs. 5.11 Git vs. patched.)
(Giovanni's earlier patch against this new patch, compared to unpatched 
Linux 5.11 Git and then Linux 5.11 with CPUfreq performance governor.)


  reply	other threads:[~2021-02-04 23:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-03 13:53 [PATCH v3 0/1] AMD EPYC: fix schedutil perf regression (freq-invariance) Giovanni Gherdovich
2021-02-03 13:53 ` [PATCH v3 1/1] x86,sched: On AMD EPYC set freq_max = max_boost in schedutil invariant formula Giovanni Gherdovich
2021-02-03 14:11   ` Rafael J. Wysocki
2021-02-03 18:25     ` Rafael J. Wysocki
2021-02-03 23:35       ` Michael Larabel
2021-02-04 13:40         ` Rafael J. Wysocki
2021-02-04 23:04           ` Michael Larabel [this message]
2021-02-05 11:42             ` Rafael J. Wysocki
2021-02-04 13:49       ` Giovanni Gherdovich
2021-02-04 13:55         ` Rafael J. Wysocki

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).