On Thu, Feb 4, 2021 at 12:36 AM Michael Larabel [off-list ref] wrote:

On 2/3/21 12:25 PM, Rafael J. Wysocki wrote:

quoted

On Wednesday, February 3, 2021 3:11:37 PM CET Rafael J. Wysocki wrote:

quoted

On Wed, Feb 3, 2021 at 2:53 PM Giovanni Gherdovich [off-list ref] wrote:
[cut]

quoted

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 <redacted>
Tested-by: Michael Larabel <redacted>
Signed-off-by: Giovanni Gherdovich <redacted>
---
  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.