Re: [PATCH v3 1/1] x86,sched: On AMD EPYC set freq_max = max_boost in schedutil invariant formula

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/4/21 7:40 AM, Rafael J. Wysocki wrote:
On Thu, Feb 4, 2021 at 12:36 AM Michael Larabel <Michael@xxxxxxxxxxxx> 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 <ggherdovich@xxxxxxx> 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 <Michael@xxxxxxxxxxxx>
Tested-by: Michael Larabel <Michael@xxxxxxxxxxxx>
Signed-off-by: Giovanni Gherdovich <ggherdovich@xxxxxxx>
---
   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 <Michael@xxxxxxxxxxxx>

[1] https://openbenchmarking.org/result/2102048-PTS-RYZEN95920 (5.10 stable vs. 5.11 Git vs. patched.) [2] https://openbenchmarking.org/result/2102048-HA-AMDEPYC7F37 (Giovanni's earlier patch against this new patch, compared to unpatched Linux 5.11 Git and then Linux 5.11 with CPUfreq performance governor.)

Michael




[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux