2019-05-27 06:55:05 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
2009-01-18 03:36:14 +00:00
|
|
|
* acpi-cpufreq.c - ACPI Processor P-States Driver
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
* Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
|
|
|
|
* Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
|
|
|
|
* Copyright (C) 2002 - 2004 Dominik Brodowski <linux@brodo.de>
|
2006-10-03 19:29:15 +00:00
|
|
|
* Copyright (C) 2006 Denis Sadykov <denis.m.sadykov@intel.com>
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
|
2016-04-05 20:28:25 +00:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/init.h>
|
2006-10-03 19:29:15 +00:00
|
|
|
#include <linux/smp.h>
|
|
|
|
#include <linux/sched.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/cpufreq.h>
|
2005-08-25 19:59:00 +00:00
|
|
|
#include <linux/compiler.h>
|
2006-09-01 21:02:24 +00:00
|
|
|
#include <linux/dmi.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 08:04:11 +00:00
|
|
|
#include <linux/slab.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
#include <linux/acpi.h>
|
2009-01-18 03:36:14 +00:00
|
|
|
#include <linux/io.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/uaccess.h>
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <acpi/processor.h>
|
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then. That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults. Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled. That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).
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")
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/
Reported-by: Michael Larabel <Michael@phoronix.com>
Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: Michael Larabel <Michael@phoronix.com>
2021-02-04 17:25:37 +00:00
|
|
|
#include <acpi/cppc_acpi.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-10-03 19:33:14 +00:00
|
|
|
#include <asm/msr.h>
|
2006-10-03 19:29:15 +00:00
|
|
|
#include <asm/processor.h>
|
|
|
|
#include <asm/cpufeature.h>
|
2020-03-20 13:13:46 +00:00
|
|
|
#include <asm/cpu_device_id.h>
|
2006-10-03 19:29:15 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
MODULE_AUTHOR("Paul Diefenbaugh, Dominik Brodowski");
|
|
|
|
MODULE_DESCRIPTION("ACPI Processor P-States Driver");
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
|
2006-10-03 19:33:14 +00:00
|
|
|
enum {
|
|
|
|
UNDEFINED_CAPABLE = 0,
|
|
|
|
SYSTEM_INTEL_MSR_CAPABLE,
|
2012-09-04 08:28:02 +00:00
|
|
|
SYSTEM_AMD_MSR_CAPABLE,
|
2006-10-03 19:33:14 +00:00
|
|
|
SYSTEM_IO_CAPABLE,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define INTEL_MSR_RANGE (0xffff)
|
2012-09-04 08:28:02 +00:00
|
|
|
#define AMD_MSR_RANGE (0x7)
|
2018-09-23 09:37:38 +00:00
|
|
|
#define HYGON_MSR_RANGE (0x7)
|
2006-10-03 19:33:14 +00:00
|
|
|
|
2012-09-04 08:28:07 +00:00
|
|
|
#define MSR_K7_HWCR_CPB_DIS (1ULL << 25)
|
|
|
|
|
2006-10-03 19:29:15 +00:00
|
|
|
struct acpi_cpufreq_data {
|
2006-10-03 19:35:23 +00:00
|
|
|
unsigned int resume;
|
|
|
|
unsigned int cpu_feature;
|
2015-07-10 06:36:20 +00:00
|
|
|
unsigned int acpi_perf_cpu;
|
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then. That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults. Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled. That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).
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")
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/
Reported-by: Michael Larabel <Michael@phoronix.com>
Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: Michael Larabel <Michael@phoronix.com>
2021-02-04 17:25:37 +00:00
|
|
|
unsigned int first_perf_state;
|
2013-06-27 07:08:54 +00:00
|
|
|
cpumask_var_t freqdomain_cpus;
|
2016-03-02 02:05:22 +00:00
|
|
|
void (*cpu_freq_write)(struct acpi_pct_register *reg, u32 val);
|
|
|
|
u32 (*cpu_freq_read)(struct acpi_pct_register *reg);
|
2005-04-16 22:20:36 +00:00
|
|
|
};
|
|
|
|
|
2007-08-07 22:40:30 +00:00
|
|
|
/* acpi_perf_data is a pointer to percpu data. */
|
2010-08-13 14:00:11 +00:00
|
|
|
static struct acpi_processor_performance __percpu *acpi_perf_data;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2015-07-22 20:11:56 +00:00
|
|
|
static inline struct acpi_processor_performance *to_perf_data(struct acpi_cpufreq_data *data)
|
|
|
|
{
|
|
|
|
return per_cpu_ptr(acpi_perf_data, data->acpi_perf_cpu);
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
static struct cpufreq_driver acpi_cpufreq_driver;
|
|
|
|
|
2005-08-25 19:59:00 +00:00
|
|
|
static unsigned int acpi_pstate_strict;
|
2012-09-04 08:28:07 +00:00
|
|
|
|
|
|
|
static bool boost_state(unsigned int cpu)
|
|
|
|
{
|
|
|
|
u32 lo, hi;
|
|
|
|
u64 msr;
|
|
|
|
|
|
|
|
switch (boot_cpu_data.x86_vendor) {
|
|
|
|
case X86_VENDOR_INTEL:
|
|
|
|
rdmsr_on_cpu(cpu, MSR_IA32_MISC_ENABLE, &lo, &hi);
|
|
|
|
msr = lo | ((u64)hi << 32);
|
|
|
|
return !(msr & MSR_IA32_MISC_ENABLE_TURBO_DISABLE);
|
2018-09-23 09:37:38 +00:00
|
|
|
case X86_VENDOR_HYGON:
|
2012-09-04 08:28:07 +00:00
|
|
|
case X86_VENDOR_AMD:
|
|
|
|
rdmsr_on_cpu(cpu, MSR_K7_HWCR, &lo, &hi);
|
|
|
|
msr = lo | ((u64)hi << 32);
|
|
|
|
return !(msr & MSR_K7_HWCR_CPB_DIS);
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-11-28 09:52:03 +00:00
|
|
|
static int boost_set_msr(bool enable)
|
2012-09-04 08:28:07 +00:00
|
|
|
{
|
|
|
|
u32 msr_addr;
|
2016-11-28 09:52:03 +00:00
|
|
|
u64 msr_mask, val;
|
2012-09-04 08:28:07 +00:00
|
|
|
|
|
|
|
switch (boot_cpu_data.x86_vendor) {
|
|
|
|
case X86_VENDOR_INTEL:
|
|
|
|
msr_addr = MSR_IA32_MISC_ENABLE;
|
|
|
|
msr_mask = MSR_IA32_MISC_ENABLE_TURBO_DISABLE;
|
|
|
|
break;
|
2018-09-23 09:37:38 +00:00
|
|
|
case X86_VENDOR_HYGON:
|
2012-09-04 08:28:07 +00:00
|
|
|
case X86_VENDOR_AMD:
|
|
|
|
msr_addr = MSR_K7_HWCR;
|
|
|
|
msr_mask = MSR_K7_HWCR_CPB_DIS;
|
|
|
|
break;
|
|
|
|
default:
|
2016-11-28 09:52:03 +00:00
|
|
|
return -EINVAL;
|
2012-09-04 08:28:07 +00:00
|
|
|
}
|
|
|
|
|
2016-11-28 09:52:03 +00:00
|
|
|
rdmsrl(msr_addr, val);
|
2012-09-04 08:28:07 +00:00
|
|
|
|
2016-11-28 09:52:03 +00:00
|
|
|
if (enable)
|
|
|
|
val &= ~msr_mask;
|
|
|
|
else
|
|
|
|
val |= msr_mask;
|
2012-09-04 08:28:07 +00:00
|
|
|
|
2016-11-28 09:52:03 +00:00
|
|
|
wrmsrl(msr_addr, val);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void boost_set_msr_each(void *p_en)
|
|
|
|
{
|
|
|
|
bool enable = (bool) p_en;
|
|
|
|
|
|
|
|
boost_set_msr(enable);
|
2012-09-04 08:28:07 +00:00
|
|
|
}
|
|
|
|
|
2020-05-30 02:08:30 +00:00
|
|
|
static int set_boost(struct cpufreq_policy *policy, int val)
|
2012-09-04 08:28:07 +00:00
|
|
|
{
|
2020-05-30 02:08:30 +00:00
|
|
|
on_each_cpu_mask(policy->cpus, boost_set_msr_each,
|
|
|
|
(void *)(long)val, 1);
|
|
|
|
pr_debug("CPU %*pbl: Core Boosting %sabled.\n",
|
|
|
|
cpumask_pr_args(policy->cpus), val ? "en" : "dis");
|
2012-09-04 08:28:07 +00:00
|
|
|
|
2013-12-20 14:24:50 +00:00
|
|
|
return 0;
|
2012-09-04 08:28:07 +00:00
|
|
|
}
|
|
|
|
|
2013-06-27 07:08:54 +00:00
|
|
|
static ssize_t show_freqdomain_cpus(struct cpufreq_policy *policy, char *buf)
|
|
|
|
{
|
2015-07-07 12:43:26 +00:00
|
|
|
struct acpi_cpufreq_data *data = policy->driver_data;
|
2013-06-27 07:08:54 +00:00
|
|
|
|
2015-10-07 20:50:43 +00:00
|
|
|
if (unlikely(!data))
|
|
|
|
return -ENODEV;
|
|
|
|
|
2013-06-27 07:08:54 +00:00
|
|
|
return cpufreq_show_cpus(data->freqdomain_cpus, buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
cpufreq_freq_attr_ro(freqdomain_cpus);
|
|
|
|
|
2012-09-04 08:28:08 +00:00
|
|
|
#ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
|
2015-12-26 23:25:35 +00:00
|
|
|
static ssize_t store_cpb(struct cpufreq_policy *policy, const char *buf,
|
|
|
|
size_t count)
|
2013-12-20 14:24:50 +00:00
|
|
|
{
|
|
|
|
int ret;
|
2015-12-26 23:25:35 +00:00
|
|
|
unsigned int val = 0;
|
2013-12-20 14:24:50 +00:00
|
|
|
|
2015-12-26 23:27:38 +00:00
|
|
|
if (!acpi_cpufreq_driver.set_boost)
|
2013-12-20 14:24:50 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2015-12-26 23:25:35 +00:00
|
|
|
ret = kstrtouint(buf, 10, &val);
|
|
|
|
if (ret || val > 1)
|
2013-12-20 14:24:50 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2020-05-30 02:08:30 +00:00
|
|
|
get_online_cpus();
|
|
|
|
set_boost(policy, val);
|
|
|
|
put_online_cpus();
|
2013-12-20 14:24:50 +00:00
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2012-09-04 08:28:08 +00:00
|
|
|
static ssize_t show_cpb(struct cpufreq_policy *policy, char *buf)
|
|
|
|
{
|
2013-12-20 14:24:50 +00:00
|
|
|
return sprintf(buf, "%u\n", acpi_cpufreq_driver.boost_enabled);
|
2012-09-04 08:28:08 +00:00
|
|
|
}
|
|
|
|
|
2013-08-13 02:05:53 +00:00
|
|
|
cpufreq_freq_attr_rw(cpb);
|
2012-09-04 08:28:08 +00:00
|
|
|
#endif
|
|
|
|
|
2006-10-03 19:33:14 +00:00
|
|
|
static int check_est_cpu(unsigned int cpuid)
|
|
|
|
{
|
2007-10-19 18:35:04 +00:00
|
|
|
struct cpuinfo_x86 *cpu = &cpu_data(cpuid);
|
2006-10-03 19:33:14 +00:00
|
|
|
|
2009-06-08 10:27:54 +00:00
|
|
|
return cpu_has(cpu, X86_FEATURE_EST);
|
2006-10-03 19:33:14 +00:00
|
|
|
}
|
|
|
|
|
2012-09-04 08:28:02 +00:00
|
|
|
static int check_amd_hwpstate_cpu(unsigned int cpuid)
|
|
|
|
{
|
|
|
|
struct cpuinfo_x86 *cpu = &cpu_data(cpuid);
|
|
|
|
|
|
|
|
return cpu_has(cpu, X86_FEATURE_HW_PSTATE);
|
|
|
|
}
|
|
|
|
|
2016-04-07 08:36:57 +00:00
|
|
|
static unsigned extract_io(struct cpufreq_policy *policy, u32 value)
|
2006-10-03 19:29:15 +00:00
|
|
|
{
|
2016-04-07 08:36:57 +00:00
|
|
|
struct acpi_cpufreq_data *data = policy->driver_data;
|
2006-10-03 19:35:23 +00:00
|
|
|
struct acpi_processor_performance *perf;
|
|
|
|
int i;
|
2006-10-03 19:29:15 +00:00
|
|
|
|
2015-07-22 20:11:56 +00:00
|
|
|
perf = to_perf_data(data);
|
2006-10-03 19:29:15 +00:00
|
|
|
|
2009-01-18 03:36:14 +00:00
|
|
|
for (i = 0; i < perf->state_count; i++) {
|
2006-10-03 19:29:15 +00:00
|
|
|
if (value == perf->states[i].status)
|
2016-04-07 08:36:57 +00:00
|
|
|
return policy->freq_table[i].frequency;
|
2006-10-03 19:29:15 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-04-07 08:36:57 +00:00
|
|
|
static unsigned extract_msr(struct cpufreq_policy *policy, u32 msr)
|
2006-10-03 19:33:14 +00:00
|
|
|
{
|
2016-04-07 08:36:57 +00:00
|
|
|
struct acpi_cpufreq_data *data = policy->driver_data;
|
2014-04-25 20:15:38 +00:00
|
|
|
struct cpufreq_frequency_table *pos;
|
2006-10-03 19:37:42 +00:00
|
|
|
struct acpi_processor_performance *perf;
|
2006-10-03 19:33:14 +00:00
|
|
|
|
2012-09-04 08:28:02 +00:00
|
|
|
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
|
|
|
|
msr &= AMD_MSR_RANGE;
|
2018-09-23 09:37:38 +00:00
|
|
|
else if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
|
|
|
|
msr &= HYGON_MSR_RANGE;
|
2012-09-04 08:28:02 +00:00
|
|
|
else
|
|
|
|
msr &= INTEL_MSR_RANGE;
|
|
|
|
|
2015-07-22 20:11:56 +00:00
|
|
|
perf = to_perf_data(data);
|
2006-10-03 19:37:42 +00:00
|
|
|
|
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then. That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults. Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled. That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).
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")
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/
Reported-by: Michael Larabel <Michael@phoronix.com>
Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: Michael Larabel <Michael@phoronix.com>
2021-02-04 17:25:37 +00:00
|
|
|
cpufreq_for_each_entry(pos, policy->freq_table + data->first_perf_state)
|
2014-04-25 20:15:38 +00:00
|
|
|
if (msr == perf->states[pos->driver_data].status)
|
|
|
|
return pos->frequency;
|
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then. That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults. Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled. That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).
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")
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/
Reported-by: Michael Larabel <Michael@phoronix.com>
Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: Michael Larabel <Michael@phoronix.com>
2021-02-04 17:25:37 +00:00
|
|
|
return policy->freq_table[data->first_perf_state].frequency;
|
2006-10-03 19:33:14 +00:00
|
|
|
}
|
|
|
|
|
2016-04-07 08:36:57 +00:00
|
|
|
static unsigned extract_freq(struct cpufreq_policy *policy, u32 val)
|
2006-10-03 19:33:14 +00:00
|
|
|
{
|
2016-04-07 08:36:57 +00:00
|
|
|
struct acpi_cpufreq_data *data = policy->driver_data;
|
|
|
|
|
2006-10-03 19:33:14 +00:00
|
|
|
switch (data->cpu_feature) {
|
2006-10-03 19:35:23 +00:00
|
|
|
case SYSTEM_INTEL_MSR_CAPABLE:
|
2012-09-04 08:28:02 +00:00
|
|
|
case SYSTEM_AMD_MSR_CAPABLE:
|
2016-04-07 08:36:57 +00:00
|
|
|
return extract_msr(policy, val);
|
2006-10-03 19:35:23 +00:00
|
|
|
case SYSTEM_IO_CAPABLE:
|
2016-04-07 08:36:57 +00:00
|
|
|
return extract_io(policy, val);
|
2006-10-03 19:35:23 +00:00
|
|
|
default:
|
2006-10-03 19:33:14 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-03-22 14:34:30 +00:00
|
|
|
static u32 cpu_freq_read_intel(struct acpi_pct_register *not_used)
|
2016-03-02 02:05:22 +00:00
|
|
|
{
|
2020-07-15 08:26:29 +00:00
|
|
|
u32 val, dummy __always_unused;
|
2006-10-03 19:33:14 +00:00
|
|
|
|
2016-03-02 02:05:22 +00:00
|
|
|
rdmsr(MSR_IA32_PERF_CTL, val, dummy);
|
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
2016-03-22 14:34:30 +00:00
|
|
|
static void cpu_freq_write_intel(struct acpi_pct_register *not_used, u32 val)
|
2016-03-02 02:05:22 +00:00
|
|
|
{
|
|
|
|
u32 lo, hi;
|
|
|
|
|
|
|
|
rdmsr(MSR_IA32_PERF_CTL, lo, hi);
|
|
|
|
lo = (lo & ~INTEL_MSR_RANGE) | (val & INTEL_MSR_RANGE);
|
|
|
|
wrmsr(MSR_IA32_PERF_CTL, lo, hi);
|
|
|
|
}
|
|
|
|
|
2016-03-22 14:34:30 +00:00
|
|
|
static u32 cpu_freq_read_amd(struct acpi_pct_register *not_used)
|
2016-03-02 02:05:22 +00:00
|
|
|
{
|
2020-07-15 08:26:29 +00:00
|
|
|
u32 val, dummy __always_unused;
|
2016-03-02 02:05:22 +00:00
|
|
|
|
|
|
|
rdmsr(MSR_AMD_PERF_CTL, val, dummy);
|
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
2016-03-22 14:34:30 +00:00
|
|
|
static void cpu_freq_write_amd(struct acpi_pct_register *not_used, u32 val)
|
2016-03-02 02:05:22 +00:00
|
|
|
{
|
|
|
|
wrmsr(MSR_AMD_PERF_CTL, val, 0);
|
|
|
|
}
|
|
|
|
|
2016-03-22 14:34:30 +00:00
|
|
|
static u32 cpu_freq_read_io(struct acpi_pct_register *reg)
|
2016-03-02 02:05:22 +00:00
|
|
|
{
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
acpi_os_read_port(reg->address, &val, reg->bit_width);
|
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
2016-03-22 14:34:30 +00:00
|
|
|
static void cpu_freq_write_io(struct acpi_pct_register *reg, u32 val)
|
2016-03-02 02:05:22 +00:00
|
|
|
{
|
|
|
|
acpi_os_write_port(reg->address, val, reg->bit_width);
|
|
|
|
}
|
2006-10-03 19:29:15 +00:00
|
|
|
|
|
|
|
struct drv_cmd {
|
2016-03-02 02:05:22 +00:00
|
|
|
struct acpi_pct_register *reg;
|
2006-10-03 19:29:15 +00:00
|
|
|
u32 val;
|
2016-03-02 02:05:22 +00:00
|
|
|
union {
|
|
|
|
void (*write)(struct acpi_pct_register *reg, u32 val);
|
|
|
|
u32 (*read)(struct acpi_pct_register *reg);
|
|
|
|
} func;
|
2006-10-03 19:29:15 +00:00
|
|
|
};
|
|
|
|
|
2009-04-13 17:27:49 +00:00
|
|
|
/* Called via smp_call_function_single(), on the target CPU */
|
|
|
|
static void do_drv_read(void *_cmd)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2009-01-16 23:31:15 +00:00
|
|
|
struct drv_cmd *cmd = _cmd;
|
2006-10-03 19:33:14 +00:00
|
|
|
|
2016-03-02 02:05:22 +00:00
|
|
|
cmd->val = cmd->func.read(cmd->reg);
|
2006-10-03 19:29:15 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2016-03-02 02:05:22 +00:00
|
|
|
static u32 drv_read(struct acpi_cpufreq_data *data, const struct cpumask *mask)
|
2006-10-03 19:29:15 +00:00
|
|
|
{
|
2016-03-02 02:05:22 +00:00
|
|
|
struct acpi_processor_performance *perf = to_perf_data(data);
|
|
|
|
struct drv_cmd cmd = {
|
|
|
|
.reg = &perf->control_register,
|
|
|
|
.func.read = data->cpu_freq_read,
|
|
|
|
};
|
|
|
|
int err;
|
2006-10-03 19:33:14 +00:00
|
|
|
|
2016-03-02 02:05:22 +00:00
|
|
|
err = smp_call_function_any(mask, do_drv_read, &cmd, 1);
|
|
|
|
WARN_ON_ONCE(err); /* smp_call_function_any() was buggy? */
|
|
|
|
return cmd.val;
|
2006-10-03 19:29:15 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2016-03-02 02:05:22 +00:00
|
|
|
/* Called via smp_call_function_many(), on the target CPUs */
|
|
|
|
static void do_drv_write(void *_cmd)
|
2006-10-03 19:29:15 +00:00
|
|
|
{
|
2016-03-02 02:05:22 +00:00
|
|
|
struct drv_cmd *cmd = _cmd;
|
2006-10-03 19:29:15 +00:00
|
|
|
|
2016-03-02 02:05:22 +00:00
|
|
|
cmd->func.write(cmd->reg, cmd->val);
|
2006-10-03 19:29:15 +00:00
|
|
|
}
|
|
|
|
|
2016-03-02 02:05:22 +00:00
|
|
|
static void drv_write(struct acpi_cpufreq_data *data,
|
|
|
|
const struct cpumask *mask, u32 val)
|
2006-10-03 19:29:15 +00:00
|
|
|
{
|
2016-03-02 02:05:22 +00:00
|
|
|
struct acpi_processor_performance *perf = to_perf_data(data);
|
|
|
|
struct drv_cmd cmd = {
|
|
|
|
.reg = &perf->control_register,
|
|
|
|
.val = val,
|
|
|
|
.func.write = data->cpu_freq_write,
|
|
|
|
};
|
2009-04-15 15:05:13 +00:00
|
|
|
int this_cpu;
|
|
|
|
|
|
|
|
this_cpu = get_cpu();
|
2016-03-02 02:05:22 +00:00
|
|
|
if (cpumask_test_cpu(this_cpu, mask))
|
|
|
|
do_drv_write(&cmd);
|
|
|
|
|
|
|
|
smp_call_function_many(mask, do_drv_write, &cmd, 1);
|
2009-04-15 15:05:13 +00:00
|
|
|
put_cpu();
|
2006-10-03 19:29:15 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2016-03-02 02:05:22 +00:00
|
|
|
static u32 get_cur_val(const struct cpumask *mask, struct acpi_cpufreq_data *data)
|
2006-10-03 19:29:15 +00:00
|
|
|
{
|
2016-03-02 02:05:22 +00:00
|
|
|
u32 val;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-01-04 13:18:08 +00:00
|
|
|
if (unlikely(cpumask_empty(mask)))
|
2006-10-03 19:29:15 +00:00
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2016-03-02 02:05:22 +00:00
|
|
|
val = drv_read(data, mask);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-04-15 11:03:58 +00:00
|
|
|
pr_debug("%s = %u\n", __func__, val);
|
2006-10-03 19:29:15 +00:00
|
|
|
|
2016-03-02 02:05:22 +00:00
|
|
|
return val;
|
2006-10-03 19:29:15 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-10-03 19:29:15 +00:00
|
|
|
static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
|
|
|
|
{
|
2015-07-07 12:43:26 +00:00
|
|
|
struct acpi_cpufreq_data *data;
|
|
|
|
struct cpufreq_policy *policy;
|
2006-10-03 19:35:23 +00:00
|
|
|
unsigned int freq;
|
2008-04-28 19:13:43 +00:00
|
|
|
unsigned int cached_freq;
|
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then. That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults. Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled. That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).
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")
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/
Reported-by: Michael Larabel <Michael@phoronix.com>
Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: Michael Larabel <Michael@phoronix.com>
2021-02-04 17:25:37 +00:00
|
|
|
unsigned int state;
|
2006-10-03 19:29:15 +00:00
|
|
|
|
2019-04-15 11:03:58 +00:00
|
|
|
pr_debug("%s (%d)\n", __func__, cpu);
|
2006-10-03 19:29:15 +00:00
|
|
|
|
2015-09-16 00:17:49 +00:00
|
|
|
policy = cpufreq_cpu_get_raw(cpu);
|
2015-07-07 12:43:26 +00:00
|
|
|
if (unlikely(!policy))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
data = policy->driver_data;
|
2016-04-07 08:36:57 +00:00
|
|
|
if (unlikely(!data || !policy->freq_table))
|
2006-10-03 19:29:15 +00:00
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then. That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults. Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled. That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).
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")
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/
Reported-by: Michael Larabel <Michael@phoronix.com>
Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: Michael Larabel <Michael@phoronix.com>
2021-02-04 17:25:37 +00:00
|
|
|
state = to_perf_data(data)->state;
|
|
|
|
if (state < data->first_perf_state)
|
|
|
|
state = data->first_perf_state;
|
|
|
|
|
|
|
|
cached_freq = policy->freq_table[state].frequency;
|
2016-04-07 08:36:57 +00:00
|
|
|
freq = extract_freq(policy, get_cur_val(cpumask_of(cpu), data));
|
2008-04-28 19:13:43 +00:00
|
|
|
if (freq != cached_freq) {
|
|
|
|
/*
|
|
|
|
* The dreaded BIOS frequency change behind our back.
|
|
|
|
* Force set the frequency on next target call.
|
|
|
|
*/
|
|
|
|
data->resume = 1;
|
|
|
|
}
|
|
|
|
|
2011-03-27 13:04:46 +00:00
|
|
|
pr_debug("cur freq = %u\n", freq);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-10-03 19:29:15 +00:00
|
|
|
return freq;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2016-04-07 08:36:57 +00:00
|
|
|
static unsigned int check_freqs(struct cpufreq_policy *policy,
|
|
|
|
const struct cpumask *mask, unsigned int freq)
|
2006-10-03 19:29:15 +00:00
|
|
|
{
|
2016-04-07 08:36:57 +00:00
|
|
|
struct acpi_cpufreq_data *data = policy->driver_data;
|
2006-10-03 19:35:23 +00:00
|
|
|
unsigned int cur_freq;
|
|
|
|
unsigned int i;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-01-18 03:36:14 +00:00
|
|
|
for (i = 0; i < 100; i++) {
|
2016-04-07 08:36:57 +00:00
|
|
|
cur_freq = extract_freq(policy, get_cur_val(mask, data));
|
2006-10-03 19:29:15 +00:00
|
|
|
if (cur_freq == freq)
|
|
|
|
return 1;
|
|
|
|
udelay(10);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_cpufreq_target(struct cpufreq_policy *policy,
|
2013-10-25 14:15:48 +00:00
|
|
|
unsigned int index)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2015-07-07 12:43:26 +00:00
|
|
|
struct acpi_cpufreq_data *data = policy->driver_data;
|
2006-10-03 19:35:23 +00:00
|
|
|
struct acpi_processor_performance *perf;
|
2016-03-02 02:05:22 +00:00
|
|
|
const struct cpumask *mask;
|
2006-12-19 20:58:55 +00:00
|
|
|
unsigned int next_perf_state = 0; /* Index into perf table */
|
2006-10-03 19:35:23 +00:00
|
|
|
int result = 0;
|
2006-10-03 19:29:15 +00:00
|
|
|
|
2016-04-07 08:36:57 +00:00
|
|
|
if (unlikely(!data)) {
|
2006-10-03 19:29:15 +00:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2015-07-22 20:11:56 +00:00
|
|
|
perf = to_perf_data(data);
|
2016-04-07 08:36:57 +00:00
|
|
|
next_perf_state = policy->freq_table[index].driver_data;
|
2006-10-03 19:36:30 +00:00
|
|
|
if (perf->state == next_perf_state) {
|
2006-10-03 19:29:15 +00:00
|
|
|
if (unlikely(data->resume)) {
|
2011-03-27 13:04:46 +00:00
|
|
|
pr_debug("Called after resume, resetting to P%d\n",
|
2006-10-03 19:35:23 +00:00
|
|
|
next_perf_state);
|
2006-10-03 19:29:15 +00:00
|
|
|
data->resume = 0;
|
|
|
|
} else {
|
2011-03-27 13:04:46 +00:00
|
|
|
pr_debug("Already at target state (P%d)\n",
|
2006-10-03 19:35:23 +00:00
|
|
|
next_perf_state);
|
2016-02-25 23:03:58 +00:00
|
|
|
return 0;
|
2006-10-03 19:29:15 +00:00
|
|
|
}
|
2005-12-14 20:05:00 +00:00
|
|
|
}
|
|
|
|
|
2016-03-02 02:05:22 +00:00
|
|
|
/*
|
|
|
|
* The core won't allow CPUs to go away until the governor has been
|
|
|
|
* stopped, so we can rely on the stability of policy->cpus.
|
|
|
|
*/
|
|
|
|
mask = policy->shared_type == CPUFREQ_SHARED_TYPE_ANY ?
|
|
|
|
cpumask_of(policy->cpu) : policy->cpus;
|
2005-12-14 20:05:00 +00:00
|
|
|
|
2016-03-02 02:05:22 +00:00
|
|
|
drv_write(data, mask, perf->states[next_perf_state].control);
|
2005-12-14 20:05:00 +00:00
|
|
|
|
2006-10-03 19:29:15 +00:00
|
|
|
if (acpi_pstate_strict) {
|
2016-04-07 08:36:57 +00:00
|
|
|
if (!check_freqs(policy, mask,
|
|
|
|
policy->freq_table[index].frequency)) {
|
2019-04-15 11:03:58 +00:00
|
|
|
pr_debug("%s (%d)\n", __func__, policy->cpu);
|
2009-01-04 13:18:08 +00:00
|
|
|
result = -EAGAIN;
|
2005-12-14 20:05:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-06-19 08:52:55 +00:00
|
|
|
if (!result)
|
|
|
|
perf->state = next_perf_state;
|
2006-10-03 19:29:15 +00:00
|
|
|
|
|
|
|
return result;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2018-06-01 13:05:12 +00:00
|
|
|
static unsigned int acpi_cpufreq_fast_switch(struct cpufreq_policy *policy,
|
|
|
|
unsigned int target_freq)
|
2016-03-30 01:47:49 +00:00
|
|
|
{
|
|
|
|
struct acpi_cpufreq_data *data = policy->driver_data;
|
|
|
|
struct acpi_processor_performance *perf;
|
|
|
|
struct cpufreq_frequency_table *entry;
|
2016-06-27 04:29:34 +00:00
|
|
|
unsigned int next_perf_state, next_freq, index;
|
2016-03-30 01:47:49 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the closest frequency above target_freq.
|
|
|
|
*/
|
2016-07-13 20:25:27 +00:00
|
|
|
if (policy->cached_target_freq == target_freq)
|
|
|
|
index = policy->cached_resolved_idx;
|
|
|
|
else
|
|
|
|
index = cpufreq_table_find_index_dl(policy, target_freq);
|
2016-06-27 04:29:34 +00:00
|
|
|
|
|
|
|
entry = &policy->freq_table[index];
|
2016-03-30 01:47:49 +00:00
|
|
|
next_freq = entry->frequency;
|
|
|
|
next_perf_state = entry->driver_data;
|
|
|
|
|
|
|
|
perf = to_perf_data(data);
|
|
|
|
if (perf->state == next_perf_state) {
|
|
|
|
if (unlikely(data->resume))
|
|
|
|
data->resume = 0;
|
|
|
|
else
|
|
|
|
return next_freq;
|
|
|
|
}
|
|
|
|
|
|
|
|
data->cpu_freq_write(&perf->control_register,
|
|
|
|
perf->states[next_perf_state].control);
|
|
|
|
perf->state = next_perf_state;
|
|
|
|
return next_freq;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
static unsigned long
|
2006-10-03 19:35:23 +00:00
|
|
|
acpi_cpufreq_guess_freq(struct acpi_cpufreq_data *data, unsigned int cpu)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2015-07-22 20:11:56 +00:00
|
|
|
struct acpi_processor_performance *perf;
|
2005-12-14 20:05:00 +00:00
|
|
|
|
2015-07-22 20:11:56 +00:00
|
|
|
perf = to_perf_data(data);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (cpu_khz) {
|
|
|
|
/* search the closest match to cpu_khz */
|
|
|
|
unsigned int i;
|
|
|
|
unsigned long freq;
|
2005-12-14 20:05:00 +00:00
|
|
|
unsigned long freqn = perf->states[0].core_frequency * 1000;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-01-18 03:36:14 +00:00
|
|
|
for (i = 0; i < (perf->state_count-1); i++) {
|
2005-04-16 22:20:36 +00:00
|
|
|
freq = freqn;
|
2006-10-18 04:41:48 +00:00
|
|
|
freqn = perf->states[i+1].core_frequency * 1000;
|
2005-04-16 22:20:36 +00:00
|
|
|
if ((2 * cpu_khz) > (freqn + freq)) {
|
2005-12-14 20:05:00 +00:00
|
|
|
perf->state = i;
|
2006-10-03 19:35:23 +00:00
|
|
|
return freq;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
}
|
2006-10-18 04:41:48 +00:00
|
|
|
perf->state = perf->state_count-1;
|
2006-10-03 19:35:23 +00:00
|
|
|
return freqn;
|
2005-12-14 20:05:00 +00:00
|
|
|
} else {
|
2005-04-16 22:20:36 +00:00
|
|
|
/* assume CPU is at P0... */
|
2005-12-14 20:05:00 +00:00
|
|
|
perf->state = 0;
|
|
|
|
return perf->states[0].core_frequency * 1000;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2009-01-01 02:08:47 +00:00
|
|
|
static void free_acpi_perf_data(void)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
/* Freeing a NULL pointer is OK, and alloc_percpu zeroes. */
|
|
|
|
for_each_possible_cpu(i)
|
|
|
|
free_cpumask_var(per_cpu_ptr(acpi_perf_data, i)
|
|
|
|
->shared_cpu_map);
|
|
|
|
free_percpu(acpi_perf_data);
|
|
|
|
}
|
|
|
|
|
2016-11-28 09:51:02 +00:00
|
|
|
static int cpufreq_boost_online(unsigned int cpu)
|
2012-09-04 08:28:07 +00:00
|
|
|
{
|
|
|
|
/*
|
2016-11-28 09:51:02 +00:00
|
|
|
* On the CPU_UP path we simply keep the boost-disable flag
|
|
|
|
* in sync with the current global state.
|
2012-09-04 08:28:07 +00:00
|
|
|
*/
|
2016-11-28 09:52:03 +00:00
|
|
|
return boost_set_msr(acpi_cpufreq_driver.boost_enabled);
|
2016-11-28 09:51:02 +00:00
|
|
|
}
|
2012-09-04 08:28:07 +00:00
|
|
|
|
2016-11-28 09:51:02 +00:00
|
|
|
static int cpufreq_boost_down_prep(unsigned int cpu)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Clear the boost-disable bit on the CPU_DOWN path so that
|
|
|
|
* this cpu cannot block the remaining ones from boosting.
|
|
|
|
*/
|
2016-11-28 09:52:03 +00:00
|
|
|
return boost_set_msr(1);
|
2012-09-04 08:28:07 +00:00
|
|
|
}
|
|
|
|
|
2005-12-14 20:05:00 +00:00
|
|
|
/*
|
|
|
|
* acpi_cpufreq_early_init - initialize ACPI P-States library
|
|
|
|
*
|
|
|
|
* Initialize the ACPI P-States library (drivers/acpi/processor_perflib.c)
|
|
|
|
* in order to determine correct frequency and voltage pairings. We can
|
|
|
|
* do _PDC and _PSD and find out the processor dependency for the
|
|
|
|
* actual init that will happen later...
|
|
|
|
*/
|
2007-08-07 22:40:30 +00:00
|
|
|
static int __init acpi_cpufreq_early_init(void)
|
2005-12-14 20:05:00 +00:00
|
|
|
{
|
2009-01-01 02:08:47 +00:00
|
|
|
unsigned int i;
|
2019-04-15 11:03:58 +00:00
|
|
|
pr_debug("%s\n", __func__);
|
2005-12-14 20:05:00 +00:00
|
|
|
|
2007-08-07 22:40:30 +00:00
|
|
|
acpi_perf_data = alloc_percpu(struct acpi_processor_performance);
|
|
|
|
if (!acpi_perf_data) {
|
2011-03-27 13:04:46 +00:00
|
|
|
pr_debug("Memory allocation error for acpi_perf_data.\n");
|
2007-08-07 22:40:30 +00:00
|
|
|
return -ENOMEM;
|
2005-12-14 20:05:00 +00:00
|
|
|
}
|
2009-01-01 02:08:47 +00:00
|
|
|
for_each_possible_cpu(i) {
|
2009-06-06 21:51:36 +00:00
|
|
|
if (!zalloc_cpumask_var_node(
|
2009-01-01 02:08:47 +00:00
|
|
|
&per_cpu_ptr(acpi_perf_data, i)->shared_cpu_map,
|
|
|
|
GFP_KERNEL, cpu_to_node(i))) {
|
2009-01-01 02:08:47 +00:00
|
|
|
|
|
|
|
/* Freeing a NULL pointer is OK: alloc_percpu zeroes. */
|
|
|
|
free_acpi_perf_data();
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
}
|
2005-12-14 20:05:00 +00:00
|
|
|
|
|
|
|
/* Do initialization in ACPI core */
|
2006-10-03 19:29:15 +00:00
|
|
|
acpi_processor_preregister_performance(acpi_perf_data);
|
|
|
|
return 0;
|
2005-12-14 20:05:00 +00:00
|
|
|
}
|
|
|
|
|
2006-10-21 05:37:39 +00:00
|
|
|
#ifdef CONFIG_SMP
|
2006-09-01 21:02:24 +00:00
|
|
|
/*
|
|
|
|
* Some BIOSes do SW_ANY coordination internally, either set it up in hw
|
|
|
|
* or do it in BIOS firmware and won't inform about it to OS. If not
|
|
|
|
* detected, this has a side effect of making CPU run at a different speed
|
|
|
|
* than OS intended it to run at. Detect it and handle it cleanly.
|
|
|
|
*/
|
|
|
|
static int bios_with_sw_any_bug;
|
|
|
|
|
2007-10-03 19:15:40 +00:00
|
|
|
static int sw_any_bug_found(const struct dmi_system_id *d)
|
2006-09-01 21:02:24 +00:00
|
|
|
{
|
|
|
|
bios_with_sw_any_bug = 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-10-03 19:15:40 +00:00
|
|
|
static const struct dmi_system_id sw_any_bug_dmi_table[] = {
|
2006-09-01 21:02:24 +00:00
|
|
|
{
|
|
|
|
.callback = sw_any_bug_found,
|
|
|
|
.ident = "Supermicro Server X6DLP",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Supermicro"),
|
|
|
|
DMI_MATCH(DMI_BIOS_VERSION, "080010"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X6DLP"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
{ }
|
|
|
|
};
|
2009-08-26 17:19:37 +00:00
|
|
|
|
|
|
|
static int acpi_cpufreq_blacklist(struct cpuinfo_x86 *c)
|
|
|
|
{
|
2009-09-25 17:30:08 +00:00
|
|
|
/* Intel Xeon Processor 7100 Series Specification Update
|
2020-07-13 10:55:02 +00:00
|
|
|
* https://www.intel.com/Assets/PDF/specupdate/314554.pdf
|
2009-08-26 17:19:37 +00:00
|
|
|
* AL30: A Machine Check Exception (MCE) Occurring during an
|
|
|
|
* Enhanced Intel SpeedStep Technology Ratio Change May Cause
|
2009-09-25 17:30:08 +00:00
|
|
|
* Both Processor Cores to Lock Up. */
|
2009-08-26 17:19:37 +00:00
|
|
|
if (c->x86_vendor == X86_VENDOR_INTEL) {
|
|
|
|
if ((c->x86 == 15) &&
|
|
|
|
(c->x86_model == 6) &&
|
2018-01-01 01:52:10 +00:00
|
|
|
(c->x86_stepping == 8)) {
|
2016-04-05 20:28:25 +00:00
|
|
|
pr_info("Intel(R) Xeon(R) 7100 Errata AL30, processors may lock up on frequency changes: disabling acpi-cpufreq\n");
|
2009-08-26 17:19:37 +00:00
|
|
|
return -ENODEV;
|
2009-09-25 17:30:08 +00:00
|
|
|
}
|
2009-08-26 17:19:37 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2006-10-21 05:37:39 +00:00
|
|
|
#endif
|
2006-09-01 21:02:24 +00:00
|
|
|
|
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then. That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults. Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled. That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).
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")
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/
Reported-by: Michael Larabel <Michael@phoronix.com>
Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: Michael Larabel <Michael@phoronix.com>
2021-02-04 17:25:37 +00:00
|
|
|
#ifdef CONFIG_ACPI_CPPC_LIB
|
|
|
|
static u64 get_max_boost_ratio(unsigned int cpu)
|
|
|
|
{
|
|
|
|
struct cppc_perf_caps perf_caps;
|
|
|
|
u64 highest_perf, nominal_perf;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (acpi_pstate_strict)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
ret = cppc_get_perf_caps(cpu, &perf_caps);
|
|
|
|
if (ret) {
|
|
|
|
pr_debug("CPU%d: Unable to get performance capabilities (%d)\n",
|
|
|
|
cpu, ret);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
highest_perf = perf_caps.highest_perf;
|
|
|
|
nominal_perf = perf_caps.nominal_perf;
|
|
|
|
|
|
|
|
if (!highest_perf || !nominal_perf) {
|
|
|
|
pr_debug("CPU%d: highest or nominal performance missing\n", cpu);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (highest_perf < nominal_perf) {
|
|
|
|
pr_debug("CPU%d: nominal performance above highest\n", cpu);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return div_u64(highest_perf << SCHED_CAPACITY_SHIFT, nominal_perf);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline u64 get_max_boost_ratio(unsigned int cpu) { return 0; }
|
|
|
|
#endif
|
|
|
|
|
2006-10-03 19:35:23 +00:00
|
|
|
static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then. That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults. Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled. That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).
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")
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/
Reported-by: Michael Larabel <Michael@phoronix.com>
Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: Michael Larabel <Michael@phoronix.com>
2021-02-04 17:25:37 +00:00
|
|
|
struct cpufreq_frequency_table *freq_table;
|
|
|
|
struct acpi_processor_performance *perf;
|
2006-10-03 19:35:23 +00:00
|
|
|
struct acpi_cpufreq_data *data;
|
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then. That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults. Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled. That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).
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")
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/
Reported-by: Michael Larabel <Michael@phoronix.com>
Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: Michael Larabel <Michael@phoronix.com>
2021-02-04 17:25:37 +00:00
|
|
|
unsigned int cpu = policy->cpu;
|
|
|
|
struct cpuinfo_x86 *c = &cpu_data(cpu);
|
|
|
|
unsigned int valid_states = 0;
|
2006-10-03 19:35:23 +00:00
|
|
|
unsigned int result = 0;
|
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then. That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults. Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled. That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).
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")
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/
Reported-by: Michael Larabel <Michael@phoronix.com>
Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: Michael Larabel <Michael@phoronix.com>
2021-02-04 17:25:37 +00:00
|
|
|
unsigned int state_count;
|
|
|
|
u64 max_boost_ratio;
|
|
|
|
unsigned int i;
|
2009-09-25 17:30:08 +00:00
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
static int blacklisted;
|
|
|
|
#endif
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-04-15 11:03:58 +00:00
|
|
|
pr_debug("%s\n", __func__);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-08-26 17:19:37 +00:00
|
|
|
#ifdef CONFIG_SMP
|
2009-09-25 17:30:08 +00:00
|
|
|
if (blacklisted)
|
|
|
|
return blacklisted;
|
|
|
|
blacklisted = acpi_cpufreq_blacklist(c);
|
|
|
|
if (blacklisted)
|
|
|
|
return blacklisted;
|
2009-08-26 17:19:37 +00:00
|
|
|
#endif
|
|
|
|
|
2013-08-06 17:23:06 +00:00
|
|
|
data = kzalloc(sizeof(*data), GFP_KERNEL);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (!data)
|
2006-10-03 19:35:23 +00:00
|
|
|
return -ENOMEM;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2013-06-27 07:08:54 +00:00
|
|
|
if (!zalloc_cpumask_var(&data->freqdomain_cpus, GFP_KERNEL)) {
|
|
|
|
result = -ENOMEM;
|
|
|
|
goto err_free;
|
|
|
|
}
|
|
|
|
|
2015-07-22 20:11:56 +00:00
|
|
|
perf = per_cpu_ptr(acpi_perf_data, cpu);
|
2015-07-10 06:36:20 +00:00
|
|
|
data->acpi_perf_cpu = cpu;
|
2015-07-07 12:43:26 +00:00
|
|
|
policy->driver_data = data;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-10-18 04:41:48 +00:00
|
|
|
if (cpu_has(c, X86_FEATURE_CONSTANT_TSC))
|
2006-10-03 19:29:15 +00:00
|
|
|
acpi_cpufreq_driver.flags |= CPUFREQ_CONST_LOOPS;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2015-07-22 20:11:56 +00:00
|
|
|
result = acpi_processor_register_performance(perf, cpu);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (result)
|
2013-06-27 07:08:54 +00:00
|
|
|
goto err_free_mask;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2005-12-14 20:05:00 +00:00
|
|
|
policy->shared_type = perf->shared_type;
|
2006-10-18 04:41:48 +00:00
|
|
|
|
2006-06-26 04:34:43 +00:00
|
|
|
/*
|
2006-10-18 04:41:48 +00:00
|
|
|
* Will let policy->cpus know about dependency only when software
|
2006-06-26 04:34:43 +00:00
|
|
|
* coordination is required.
|
|
|
|
*/
|
|
|
|
if (policy->shared_type == CPUFREQ_SHARED_TYPE_ALL ||
|
2006-09-01 21:02:24 +00:00
|
|
|
policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) {
|
2009-01-04 13:18:06 +00:00
|
|
|
cpumask_copy(policy->cpus, perf->shared_cpu_map);
|
2006-09-01 21:02:24 +00:00
|
|
|
}
|
2013-06-27 07:08:54 +00:00
|
|
|
cpumask_copy(data->freqdomain_cpus, perf->shared_cpu_map);
|
2006-09-01 21:02:24 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
dmi_check_system(sw_any_bug_dmi_table);
|
2013-01-31 09:44:40 +00:00
|
|
|
if (bios_with_sw_any_bug && !policy_is_shared(policy)) {
|
2006-09-01 21:02:24 +00:00
|
|
|
policy->shared_type = CPUFREQ_SHARED_TYPE_ALL;
|
2015-05-26 13:11:33 +00:00
|
|
|
cpumask_copy(policy->cpus, topology_core_cpumask(cpu));
|
2006-09-01 21:02:24 +00:00
|
|
|
}
|
2012-09-04 08:28:03 +00:00
|
|
|
|
2020-10-19 03:57:41 +00:00
|
|
|
if (check_amd_hwpstate_cpu(cpu) && boot_cpu_data.x86 < 0x19 &&
|
|
|
|
!acpi_pstate_strict) {
|
2012-09-04 08:28:03 +00:00
|
|
|
cpumask_clear(policy->cpus);
|
|
|
|
cpumask_set_cpu(cpu, policy->cpus);
|
2015-05-26 13:11:33 +00:00
|
|
|
cpumask_copy(data->freqdomain_cpus,
|
|
|
|
topology_sibling_cpumask(cpu));
|
2012-09-04 08:28:03 +00:00
|
|
|
policy->shared_type = CPUFREQ_SHARED_TYPE_HW;
|
2016-04-05 20:28:25 +00:00
|
|
|
pr_info_once("overriding BIOS provided _PSD data\n");
|
2012-09-04 08:28:03 +00:00
|
|
|
}
|
2006-09-01 21:02:24 +00:00
|
|
|
#endif
|
2005-12-14 20:05:00 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* capability check */
|
2005-12-14 20:05:00 +00:00
|
|
|
if (perf->state_count <= 1) {
|
2011-03-27 13:04:46 +00:00
|
|
|
pr_debug("No P-States\n");
|
2005-04-16 22:20:36 +00:00
|
|
|
result = -ENODEV;
|
|
|
|
goto err_unreg;
|
|
|
|
}
|
2005-12-14 20:05:00 +00:00
|
|
|
|
2006-10-03 19:29:15 +00:00
|
|
|
if (perf->control_register.space_id != perf->status_register.space_id) {
|
|
|
|
result = -ENODEV;
|
|
|
|
goto err_unreg;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (perf->control_register.space_id) {
|
2006-10-03 19:35:23 +00:00
|
|
|
case ACPI_ADR_SPACE_SYSTEM_IO:
|
2013-01-20 10:24:26 +00:00
|
|
|
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
|
|
|
|
boot_cpu_data.x86 == 0xf) {
|
|
|
|
pr_debug("AMD K8 systems must use native drivers.\n");
|
|
|
|
result = -ENODEV;
|
|
|
|
goto err_unreg;
|
|
|
|
}
|
2011-03-27 13:04:46 +00:00
|
|
|
pr_debug("SYSTEM IO addr space\n");
|
2006-10-03 19:33:14 +00:00
|
|
|
data->cpu_feature = SYSTEM_IO_CAPABLE;
|
2016-03-02 02:05:22 +00:00
|
|
|
data->cpu_freq_read = cpu_freq_read_io;
|
|
|
|
data->cpu_freq_write = cpu_freq_write_io;
|
2006-10-03 19:33:14 +00:00
|
|
|
break;
|
2006-10-03 19:35:23 +00:00
|
|
|
case ACPI_ADR_SPACE_FIXED_HARDWARE:
|
2011-03-27 13:04:46 +00:00
|
|
|
pr_debug("HARDWARE addr space\n");
|
2012-09-04 08:28:02 +00:00
|
|
|
if (check_est_cpu(cpu)) {
|
|
|
|
data->cpu_feature = SYSTEM_INTEL_MSR_CAPABLE;
|
2016-03-02 02:05:22 +00:00
|
|
|
data->cpu_freq_read = cpu_freq_read_intel;
|
|
|
|
data->cpu_freq_write = cpu_freq_write_intel;
|
2012-09-04 08:28:02 +00:00
|
|
|
break;
|
2006-10-03 19:33:14 +00:00
|
|
|
}
|
2012-09-04 08:28:02 +00:00
|
|
|
if (check_amd_hwpstate_cpu(cpu)) {
|
|
|
|
data->cpu_feature = SYSTEM_AMD_MSR_CAPABLE;
|
2016-03-02 02:05:22 +00:00
|
|
|
data->cpu_freq_read = cpu_freq_read_amd;
|
|
|
|
data->cpu_freq_write = cpu_freq_write_amd;
|
2012-09-04 08:28:02 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
result = -ENODEV;
|
|
|
|
goto err_unreg;
|
2006-10-03 19:35:23 +00:00
|
|
|
default:
|
2011-03-27 13:04:46 +00:00
|
|
|
pr_debug("Unknown addr space %d\n",
|
2006-10-03 19:35:23 +00:00
|
|
|
(u32) (perf->control_register.space_id));
|
2005-04-16 22:20:36 +00:00
|
|
|
result = -ENODEV;
|
|
|
|
goto err_unreg;
|
|
|
|
}
|
|
|
|
|
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then. That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults. Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled. That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).
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")
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/
Reported-by: Michael Larabel <Michael@phoronix.com>
Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: Michael Larabel <Michael@phoronix.com>
2021-02-04 17:25:37 +00:00
|
|
|
state_count = perf->state_count + 1;
|
|
|
|
|
|
|
|
max_boost_ratio = get_max_boost_ratio(cpu);
|
|
|
|
if (max_boost_ratio) {
|
|
|
|
/*
|
|
|
|
* Make a room for one more entry to represent the highest
|
|
|
|
* available "boost" frequency.
|
|
|
|
*/
|
|
|
|
state_count++;
|
|
|
|
valid_states++;
|
|
|
|
data->first_perf_state = valid_states;
|
2021-02-04 17:34:32 +00:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* If the maximum "boost" frequency is unknown, ask the arch
|
|
|
|
* scale-invariance code to use the "nominal" performance for
|
|
|
|
* CPU utilization scaling so as to prevent the schedutil
|
|
|
|
* governor from selecting inadequate CPU frequencies.
|
|
|
|
*/
|
|
|
|
arch_set_max_freq_ratio(true);
|
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then. That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults. Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled. That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).
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")
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/
Reported-by: Michael Larabel <Michael@phoronix.com>
Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: Michael Larabel <Michael@phoronix.com>
2021-02-04 17:25:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
freq_table = kcalloc(state_count, sizeof(*freq_table), GFP_KERNEL);
|
2016-04-07 08:36:57 +00:00
|
|
|
if (!freq_table) {
|
2005-04-16 22:20:36 +00:00
|
|
|
result = -ENOMEM;
|
|
|
|
goto err_unreg;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* detect transition latency */
|
|
|
|
policy->cpuinfo.transition_latency = 0;
|
2009-01-18 03:36:14 +00:00
|
|
|
for (i = 0; i < perf->state_count; i++) {
|
2006-10-03 19:35:23 +00:00
|
|
|
if ((perf->states[i].transition_latency * 1000) >
|
|
|
|
policy->cpuinfo.transition_latency)
|
|
|
|
policy->cpuinfo.transition_latency =
|
|
|
|
perf->states[i].transition_latency * 1000;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2009-03-19 21:41:40 +00:00
|
|
|
/* Check for high latency (>20uS) from buggy BIOSes, like on T42 */
|
|
|
|
if (perf->control_register.space_id == ACPI_ADR_SPACE_FIXED_HARDWARE &&
|
|
|
|
policy->cpuinfo.transition_latency > 20 * 1000) {
|
|
|
|
policy->cpuinfo.transition_latency = 20 * 1000;
|
2016-04-05 20:28:24 +00:00
|
|
|
pr_info_once("P-state transition latency capped at 20 uS\n");
|
2009-03-19 21:41:40 +00:00
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* table init */
|
2009-01-18 03:36:14 +00:00
|
|
|
for (i = 0; i < perf->state_count; i++) {
|
|
|
|
if (i > 0 && perf->states[i].core_frequency >=
|
2016-04-07 08:36:57 +00:00
|
|
|
freq_table[valid_states-1].frequency / 1000)
|
2006-10-03 19:29:15 +00:00
|
|
|
continue;
|
|
|
|
|
2016-04-07 08:36:57 +00:00
|
|
|
freq_table[valid_states].driver_data = i;
|
|
|
|
freq_table[valid_states].frequency =
|
2006-10-03 19:35:23 +00:00
|
|
|
perf->states[i].core_frequency * 1000;
|
2006-10-03 19:29:15 +00:00
|
|
|
valid_states++;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2016-04-07 08:36:57 +00:00
|
|
|
freq_table[valid_states].frequency = CPUFREQ_TABLE_END;
|
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then. That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults. Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled. That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).
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")
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/
Reported-by: Michael Larabel <Michael@phoronix.com>
Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: Michael Larabel <Michael@phoronix.com>
2021-02-04 17:25:37 +00:00
|
|
|
|
|
|
|
if (max_boost_ratio) {
|
|
|
|
unsigned int state = data->first_perf_state;
|
|
|
|
unsigned int freq = freq_table[state].frequency;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Because the loop above sorts the freq_table entries in the
|
|
|
|
* descending order, freq is the maximum frequency in the table.
|
|
|
|
* Assume that it corresponds to the CPPC nominal frequency and
|
|
|
|
* use it to populate the frequency field of the extra "boost"
|
|
|
|
* frequency entry.
|
|
|
|
*/
|
|
|
|
freq_table[0].frequency = freq * max_boost_ratio >> SCHED_CAPACITY_SHIFT;
|
|
|
|
/*
|
|
|
|
* The purpose of the extra "boost" frequency entry is to make
|
|
|
|
* the rest of cpufreq aware of the real maximum frequency, but
|
|
|
|
* the way to request it is the same as for the first_perf_state
|
|
|
|
* entry that is expected to cover the entire range of "boost"
|
|
|
|
* frequencies of the CPU, so copy the driver_data value from
|
|
|
|
* that entry.
|
|
|
|
*/
|
|
|
|
freq_table[0].driver_data = freq_table[state].driver_data;
|
|
|
|
}
|
|
|
|
|
2018-02-26 05:08:46 +00:00
|
|
|
policy->freq_table = freq_table;
|
2006-12-19 20:58:55 +00:00
|
|
|
perf->state = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-12-15 18:52:45 +00:00
|
|
|
switch (perf->control_register.space_id) {
|
2006-10-03 19:35:23 +00:00
|
|
|
case ACPI_ADR_SPACE_SYSTEM_IO:
|
2013-10-16 21:58:10 +00:00
|
|
|
/*
|
|
|
|
* The core will not set policy->cur, because
|
|
|
|
* cpufreq_driver->get is NULL, so we need to set it here.
|
|
|
|
* However, we have to guess it, because the current speed is
|
|
|
|
* unknown and not detectable via IO ports.
|
|
|
|
*/
|
2006-10-03 19:33:14 +00:00
|
|
|
policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
|
|
|
|
break;
|
2006-10-03 19:35:23 +00:00
|
|
|
case ACPI_ADR_SPACE_FIXED_HARDWARE:
|
2006-10-03 19:36:30 +00:00
|
|
|
acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
|
2006-10-03 19:33:14 +00:00
|
|
|
break;
|
2006-10-03 19:35:23 +00:00
|
|
|
default:
|
2006-10-03 19:33:14 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* notify BIOS that we exist */
|
|
|
|
acpi_processor_notify_smm(THIS_MODULE);
|
|
|
|
|
2011-03-27 13:04:46 +00:00
|
|
|
pr_debug("CPU%u - ACPI performance management activated.\n", cpu);
|
2005-12-14 20:05:00 +00:00
|
|
|
for (i = 0; i < perf->state_count; i++)
|
2011-03-27 13:04:46 +00:00
|
|
|
pr_debug(" %cP%d: %d MHz, %d mW, %d uS\n",
|
2006-10-03 19:35:23 +00:00
|
|
|
(i == perf->state ? '*' : ' '), i,
|
2005-12-14 20:05:00 +00:00
|
|
|
(u32) perf->states[i].core_frequency,
|
|
|
|
(u32) perf->states[i].power,
|
|
|
|
(u32) perf->states[i].transition_latency);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2005-05-18 17:49:00 +00:00
|
|
|
/*
|
|
|
|
* the first call to ->target() should result in us actually
|
|
|
|
* writing something to the appropriate registers.
|
|
|
|
*/
|
|
|
|
data->resume = 1;
|
2006-10-03 19:35:23 +00:00
|
|
|
|
2016-03-30 01:47:49 +00:00
|
|
|
policy->fast_switch_possible = !acpi_pstate_strict &&
|
|
|
|
!(policy_is_shared(policy) && policy->shared_type != CPUFREQ_SHARED_TYPE_ANY);
|
|
|
|
|
2006-10-03 19:29:15 +00:00
|
|
|
return result;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-10-18 04:41:48 +00:00
|
|
|
err_unreg:
|
2015-07-22 20:11:16 +00:00
|
|
|
acpi_processor_unregister_performance(cpu);
|
2013-06-27 07:08:54 +00:00
|
|
|
err_free_mask:
|
|
|
|
free_cpumask_var(data->freqdomain_cpus);
|
2006-10-18 04:41:48 +00:00
|
|
|
err_free:
|
2005-04-16 22:20:36 +00:00
|
|
|
kfree(data);
|
2015-07-07 12:43:26 +00:00
|
|
|
policy->driver_data = NULL;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-10-03 19:35:23 +00:00
|
|
|
return result;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2006-10-03 19:35:23 +00:00
|
|
|
static int acpi_cpufreq_cpu_exit(struct cpufreq_policy *policy)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2015-07-07 12:43:26 +00:00
|
|
|
struct acpi_cpufreq_data *data = policy->driver_data;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-04-15 11:03:58 +00:00
|
|
|
pr_debug("%s\n", __func__);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2016-04-07 08:36:58 +00:00
|
|
|
policy->fast_switch_possible = false;
|
|
|
|
policy->driver_data = NULL;
|
|
|
|
acpi_processor_unregister_performance(data->acpi_perf_cpu);
|
|
|
|
free_cpumask_var(data->freqdomain_cpus);
|
2016-04-07 08:36:57 +00:00
|
|
|
kfree(policy->freq_table);
|
2016-04-07 08:36:58 +00:00
|
|
|
kfree(data);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-10-03 19:35:23 +00:00
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2018-02-26 05:08:46 +00:00
|
|
|
static void acpi_cpufreq_cpu_ready(struct cpufreq_policy *policy)
|
|
|
|
{
|
|
|
|
struct acpi_processor_performance *perf = per_cpu_ptr(acpi_perf_data,
|
|
|
|
policy->cpu);
|
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then. That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults. Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled. That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).
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")
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/
Reported-by: Michael Larabel <Michael@phoronix.com>
Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: Michael Larabel <Michael@phoronix.com>
2021-02-04 17:25:37 +00:00
|
|
|
struct acpi_cpufreq_data *data = policy->driver_data;
|
|
|
|
unsigned int freq = policy->freq_table[data->first_perf_state].frequency;
|
2018-02-26 05:08:46 +00:00
|
|
|
|
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then. That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults. Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled. That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).
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")
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/
Reported-by: Michael Larabel <Michael@phoronix.com>
Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: Michael Larabel <Michael@phoronix.com>
2021-02-04 17:25:37 +00:00
|
|
|
if (perf->states[0].core_frequency * 1000 != freq)
|
2018-02-26 05:08:46 +00:00
|
|
|
pr_warn(FW_WARN "P-state 0 is not max freq\n");
|
|
|
|
}
|
|
|
|
|
2006-10-03 19:35:23 +00:00
|
|
|
static int acpi_cpufreq_resume(struct cpufreq_policy *policy)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2015-07-07 12:43:26 +00:00
|
|
|
struct acpi_cpufreq_data *data = policy->driver_data;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-04-15 11:03:58 +00:00
|
|
|
pr_debug("%s\n", __func__);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
data->resume = 1;
|
|
|
|
|
2006-10-03 19:35:23 +00:00
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2006-10-03 19:35:23 +00:00
|
|
|
static struct freq_attr *acpi_cpufreq_attr[] = {
|
2005-04-16 22:20:36 +00:00
|
|
|
&cpufreq_freq_attr_scaling_available_freqs,
|
2013-06-27 07:08:54 +00:00
|
|
|
&freqdomain_cpus,
|
2015-07-22 20:12:10 +00:00
|
|
|
#ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
|
|
|
|
&cpb,
|
|
|
|
#endif
|
2005-04-16 22:20:36 +00:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct cpufreq_driver acpi_cpufreq_driver = {
|
2013-10-03 14:57:56 +00:00
|
|
|
.verify = cpufreq_generic_frequency_table_verify,
|
2013-10-25 14:15:48 +00:00
|
|
|
.target_index = acpi_cpufreq_target,
|
2016-03-30 01:47:49 +00:00
|
|
|
.fast_switch = acpi_cpufreq_fast_switch,
|
2009-11-19 11:31:01 +00:00
|
|
|
.bios_limit = acpi_processor_get_bios_limit,
|
|
|
|
.init = acpi_cpufreq_cpu_init,
|
|
|
|
.exit = acpi_cpufreq_cpu_exit,
|
2018-02-26 05:08:46 +00:00
|
|
|
.ready = acpi_cpufreq_cpu_ready,
|
2009-11-19 11:31:01 +00:00
|
|
|
.resume = acpi_cpufreq_resume,
|
|
|
|
.name = "acpi-cpufreq",
|
|
|
|
.attr = acpi_cpufreq_attr,
|
2005-04-16 22:20:36 +00:00
|
|
|
};
|
|
|
|
|
2016-11-28 09:51:02 +00:00
|
|
|
static enum cpuhp_state acpi_cpufreq_online;
|
|
|
|
|
2012-09-04 08:28:07 +00:00
|
|
|
static void __init acpi_cpufreq_boost_init(void)
|
|
|
|
{
|
2016-11-28 09:51:02 +00:00
|
|
|
int ret;
|
2012-09-04 08:28:07 +00:00
|
|
|
|
2019-02-20 10:10:17 +00:00
|
|
|
if (!(boot_cpu_has(X86_FEATURE_CPB) || boot_cpu_has(X86_FEATURE_IDA))) {
|
|
|
|
pr_debug("Boost capabilities not present in the processor\n");
|
2016-11-28 09:51:02 +00:00
|
|
|
return;
|
2019-02-20 10:10:17 +00:00
|
|
|
}
|
2014-03-10 20:40:06 +00:00
|
|
|
|
2016-11-28 09:51:02 +00:00
|
|
|
acpi_cpufreq_driver.set_boost = set_boost;
|
|
|
|
acpi_cpufreq_driver.boost_enabled = boost_state(0);
|
2012-09-04 08:28:07 +00:00
|
|
|
|
2016-11-28 09:51:02 +00:00
|
|
|
/*
|
|
|
|
* This calls the online callback on all online cpu and forces all
|
|
|
|
* MSRs to the same value.
|
|
|
|
*/
|
|
|
|
ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "cpufreq/acpi:online",
|
|
|
|
cpufreq_boost_online, cpufreq_boost_down_prep);
|
|
|
|
if (ret < 0) {
|
|
|
|
pr_err("acpi_cpufreq: failed to register hotplug callbacks\n");
|
|
|
|
return;
|
2013-12-20 14:24:50 +00:00
|
|
|
}
|
2016-11-28 09:51:02 +00:00
|
|
|
acpi_cpufreq_online = ret;
|
2012-09-04 08:28:07 +00:00
|
|
|
}
|
|
|
|
|
2014-01-28 03:50:35 +00:00
|
|
|
static void acpi_cpufreq_boost_exit(void)
|
2012-09-04 08:28:07 +00:00
|
|
|
{
|
2016-12-15 15:00:58 +00:00
|
|
|
if (acpi_cpufreq_online > 0)
|
2016-11-28 09:51:02 +00:00
|
|
|
cpuhp_remove_state_nocalls(acpi_cpufreq_online);
|
2012-09-04 08:28:07 +00:00
|
|
|
}
|
|
|
|
|
2006-10-03 19:35:23 +00:00
|
|
|
static int __init acpi_cpufreq_init(void)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2007-08-07 22:40:30 +00:00
|
|
|
int ret;
|
|
|
|
|
2013-10-25 14:22:47 +00:00
|
|
|
if (acpi_disabled)
|
|
|
|
return -ENODEV;
|
|
|
|
|
2013-09-20 17:43:56 +00:00
|
|
|
/* don't keep reloading if cpufreq_driver exists */
|
|
|
|
if (cpufreq_get_current_driver())
|
2013-10-25 14:22:47 +00:00
|
|
|
return -EEXIST;
|
2008-09-25 02:04:31 +00:00
|
|
|
|
2019-04-15 11:03:58 +00:00
|
|
|
pr_debug("%s\n", __func__);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-08-07 22:40:30 +00:00
|
|
|
ret = acpi_cpufreq_early_init();
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2005-12-14 20:05:00 +00:00
|
|
|
|
2012-09-04 08:28:08 +00:00
|
|
|
#ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
|
|
|
|
/* this is a sysfs file with a strange name and an even stranger
|
|
|
|
* semantic - per CPU instantiation, but system global effect.
|
|
|
|
* Lets enable it only on AMD CPUs for compatibility reasons and
|
|
|
|
* only if configured. This is considered legacy code, which
|
|
|
|
* will probably be removed at some point in the future.
|
|
|
|
*/
|
2015-07-22 20:12:10 +00:00
|
|
|
if (!check_amd_hwpstate_cpu(0)) {
|
|
|
|
struct freq_attr **attr;
|
2012-09-04 08:28:08 +00:00
|
|
|
|
2015-07-22 20:12:10 +00:00
|
|
|
pr_debug("CPB unsupported, do not expose it\n");
|
2012-09-04 08:28:08 +00:00
|
|
|
|
2015-07-22 20:12:10 +00:00
|
|
|
for (attr = acpi_cpufreq_attr; *attr; attr++)
|
|
|
|
if (*attr == &cpb) {
|
|
|
|
*attr = NULL;
|
|
|
|
break;
|
|
|
|
}
|
2012-09-04 08:28:08 +00:00
|
|
|
}
|
|
|
|
#endif
|
2013-12-20 14:24:50 +00:00
|
|
|
acpi_cpufreq_boost_init();
|
2012-09-04 08:28:08 +00:00
|
|
|
|
2008-07-14 02:59:44 +00:00
|
|
|
ret = cpufreq_register_driver(&acpi_cpufreq_driver);
|
2014-01-28 03:50:35 +00:00
|
|
|
if (ret) {
|
2009-01-01 02:08:47 +00:00
|
|
|
free_acpi_perf_data();
|
2014-01-28 03:50:35 +00:00
|
|
|
acpi_cpufreq_boost_exit();
|
|
|
|
}
|
2008-07-14 02:59:44 +00:00
|
|
|
return ret;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2006-10-03 19:35:23 +00:00
|
|
|
static void __exit acpi_cpufreq_exit(void)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2019-04-15 11:03:58 +00:00
|
|
|
pr_debug("%s\n", __func__);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2012-09-04 08:28:07 +00:00
|
|
|
acpi_cpufreq_boost_exit();
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
cpufreq_unregister_driver(&acpi_cpufreq_driver);
|
|
|
|
|
2011-07-08 20:37:44 +00:00
|
|
|
free_acpi_perf_data();
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2005-08-25 19:59:00 +00:00
|
|
|
module_param(acpi_pstate_strict, uint, 0644);
|
2006-10-03 19:35:23 +00:00
|
|
|
MODULE_PARM_DESC(acpi_pstate_strict,
|
2006-10-18 04:41:48 +00:00
|
|
|
"value 0 or non-zero. non-zero -> strict ACPI checks are "
|
|
|
|
"performed during frequency changes.");
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
late_initcall(acpi_cpufreq_init);
|
|
|
|
module_exit(acpi_cpufreq_exit);
|
|
|
|
|
2020-07-15 08:26:30 +00:00
|
|
|
static const struct x86_cpu_id __maybe_unused acpi_cpufreq_ids[] = {
|
2020-03-24 13:51:51 +00:00
|
|
|
X86_MATCH_FEATURE(X86_FEATURE_ACPI, NULL),
|
|
|
|
X86_MATCH_FEATURE(X86_FEATURE_HW_PSTATE, NULL),
|
2013-01-22 21:33:46 +00:00
|
|
|
{}
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(x86cpu, acpi_cpufreq_ids);
|
|
|
|
|
2020-07-15 08:26:30 +00:00
|
|
|
static const struct acpi_device_id __maybe_unused processor_device_ids[] = {
|
2013-06-07 11:13:31 +00:00
|
|
|
{ACPI_PROCESSOR_OBJECT_HID, },
|
|
|
|
{ACPI_PROCESSOR_DEVICE_HID, },
|
|
|
|
{},
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(acpi, processor_device_ids);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
MODULE_ALIAS("acpi");
|