Hi all,
We would like to introduce a new AMD CPU frequency control mechanism as the
"amd-pstate" driver for modern AMD Zen based CPU series in Linux Kernel.
The new mechanism is based on Collaborative processor performance control
(CPPC) which is finer grain frequency management than legacy ACPI hardware
P-States. Current AMD CPU platforms are using the ACPI P-states driver to
manage CPU frequency and clocks with switching only in 3 P-states. AMD
P-States is to replace the ACPI P-states controls, allows a flexible,
low-latency interface for the Linux kernel to directly communicate the
performance hints to hardware.
"amd-pstate" leverages the Linux kernel governors such as *schedutil*,
*ondemand*, etc. to manage the performance hints which are provided by CPPC
hardware functionality. The first version for amd-pstate is to support one
of the Zen3 processors, and we will support more in future after we verify
the hardware and SBIOS functionalities.
There are two types of hardware implementations for amd-pstate: one is full
MSR support and another is shared memory support. It can use
X86_FEATURE_AMD_CPPC_EXT feature flag to distinguish the different types.
Using the new AMD P-States method + kernel governors (*schedutil*,
*ondemand*, ...) to manage the frequency update is the most appropriate
bridge between AMD Zen based hardware processor and Linux kernel, the
processor is able to ajust to the most efficiency frequency according to
the kernel scheduler loading.
Performance Per Watt (PPW) Caculation:
The PPW caculation is referred by below paper:
https://software.intel.com/content/dam/develop/external/us/en/documents/performance-per-what-paper.pdf
Below formula is referred from below spec to measure the PPW:
(F / t) / P = F * t / (t * E) = F / E,
"F" is the number of frames per second.
"P" is power measurd in watts.
"E" is energy measured in joules.
We use the RAPL interface with "perf" tool to get the energy data of the
package power.
The data comparsions between amd-pstate and acpi-freq module are tested on
AMD Cezanne processor:
1) TBench CPU benchmark:
+---------------------------------------------------------------------+
| |
| TBench (Performance Per Watt) |
| Higher is better |
+-------------------+------------------------+------------------------+
| | Performance Per Watt | Performance Per Watt |
| Kernel Module | (Schedutil) | (Ondemand) |
| | Unit: MB / (s * J) | Unit: MB / (s * J) |
+-------------------+------------------------+------------------------+
| | | |
| acpi-cpufreq | 3.022 | 2.969 |
| | | |
+-------------------+------------------------+------------------------+
| | | |
| amd-pstate | 3.131 | 3.284 |
| | | |
+-------------------+------------------------+------------------------+
2) Gitsource CPU benchmark:
+---------------------------------------------------------------------+
| |
| Gitsource (Performance Per Watt) |
| Higher is better |
+-------------------+------------------------+------------------------+
| | Performance Per Watt | Performance Per Watt |
| Kernel Module | (Schedutil) | (Ondemand) |
| | Unit: 1 / (s * J) | Unit: 1 / (s * J) |
+-------------------+------------------------+------------------------+
| | | |
| acpi-cpufreq | 3.42172E-07 | 2.74508E-07 |
| | | |
+-------------------+------------------------+------------------------+
| | | |
| amd-pstate | 4.09141E-07 | 3.47610E-07 |
| | | |
+-------------------+------------------------+------------------------+
3) Speedometer 2.0 CPU benchmark:
+---------------------------------------------------------------------+
| |
| Speedometer 2.0 (Performance Per Watt) |
| Higher is better |
+-------------------+------------------------+------------------------+
| | Performance Per Watt | Performance Per Watt |
| Kernel Module | (Schedutil) | (Ondemand) |
| | Unit: 1 / (s * J) | Unit: 1 / (s * J) |
+-------------------+------------------------+------------------------+
| | | |
| acpi-cpufreq | 0.116111767 | 0.110321664 |
| | | |
+-------------------+------------------------+------------------------+
| | | |
| amd-pstate | 0.115825281 | 0.122024299 |
| | | |
+-------------------+------------------------+------------------------+
According to above average data, we can see this solution has shown better
performance per watt scaling on mobile CPU benchmarks in most of cases.
These patch series depends on a "hotplug capable" CPU fix below (Only few
of CPU parts with "un-hotplug" core will encounter the issue and Mario is
working on the fix):
https://lore.kernel.org/linux-pm/20210813161842.222414-1-mario.limonciello@amd.com/
And we can see patch series in below git repo:
V1: https://git.kernel.org/pub/scm/linux/kernel/git/rui/linux.git/log/?h=amd-pstate-dev-v1
V2: https://git.kernel.org/pub/scm/linux/kernel/git/rui/linux.git/log/?h=amd-pstate-dev-v2
For details introduction, please see the patch 19.
Changes from V1 -> V2:
- cpufreq:
- - Add detailed description in the commit log.
- - Clean up the "extension" postfix in the x86 feature flag.
- - Revise cppc_set_enable helper.
- - Add a fix to check online cpus in cppc_acpi.
- - Use static calls to avoid retpolines.
- - Revise the comment style.
- - Remove amd_pstate_boost_supported() function.
- - Revise the return value in syfs attribute functions.
- cpupower:
- - Refine the commit log for cpupower patches.
- - Expose a function to get the sysfs value from specific table.
- - Move amd-pstate sysfs definitions and functions into amd helper file.
- - Move the boost init function into amd helper file and explain the
details in the commit log.
- - Remove the amd_pstate_get_data in the lib/cpufreq.c to keep the lib as
common operations.
- - Move print_speed function into misc helper file.
- - Add amd_pstate_show_perf_and_freq() function in amd helper for
cpufreq-info print.
Thanks,
Ray
Huang Rui (19):
x86/cpufreatures: add AMD Collaborative Processor Performance Control
feature flag
x86/msr: add AMD CPPC MSR definitions
cpufreq: amd: introduce a new amd pstate driver to support future
processors
cpufreq: amd: add fast switch function for amd-pstate module
cpufreq: amd: add acpi cppc function as the backend for legacy
processors
cpufreq: amd: add trace for amd-pstate module
cpufreq: amd: add boost mode support for amd-pstate
cpufreq: amd: add amd-pstate checking support check attribute
cpufreq: amd: add amd-pstate frequencies attributes
cpufreq: amd: add amd-pstate performance attributes
cpupower: add AMD P-state capability flag
cpupower: add the function to check amd-pstate enabled
cpupower: initial AMD P-state capability
cpupower: add the function to get the sysfs value from specific table
cpupower: add amd-pstate sysfs definition and access helper
cpupower: enable boost state support for amd-pstate module
cpupower: move print_speed function into misc helper
cpupower: print amd-pstate information on cpupower
Documentation: amd-pstate: add amd-pstate driver introduction
Jinzhou Su (1):
ACPI: CPPC: add cppc enable register function
Mario Limonciello (1):
ACPI: CPPC: Check online CPUs for determining _CPC is valid
Documentation/admin-guide/pm/amd_pstate.rst | 377 +++++++++
.../admin-guide/pm/working-state.rst | 1 +
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 17 +
drivers/acpi/cppc_acpi.c | 50 +-
drivers/cpufreq/Kconfig.x86 | 13 +
drivers/cpufreq/Makefile | 5 +
drivers/cpufreq/amd-pstate-trace.c | 2 +
drivers/cpufreq/amd-pstate-trace.h | 96 +++
drivers/cpufreq/amd-pstate.c | 724 ++++++++++++++++++
include/acpi/cppc_acpi.h | 5 +
tools/power/cpupower/lib/cpufreq.c | 21 +-
tools/power/cpupower/lib/cpufreq.h | 12 +
tools/power/cpupower/utils/cpufreq-info.c | 68 +-
tools/power/cpupower/utils/helpers/amd.c | 82 ++
tools/power/cpupower/utils/helpers/cpuid.c | 13 +
tools/power/cpupower/utils/helpers/helpers.h | 21 +
tools/power/cpupower/utils/helpers/misc.c | 64 ++
18 files changed, 1514 insertions(+), 58 deletions(-)
create mode 100644 Documentation/admin-guide/pm/amd_pstate.rst
create mode 100644 drivers/cpufreq/amd-pstate-trace.c
create mode 100644 drivers/cpufreq/amd-pstate-trace.h
create mode 100644 drivers/cpufreq/amd-pstate.c
--
2.25.1
Add Collaborative Processor Performance Control feature flag for AMD
processors.
This feature flag will be used on the following amd-pstate driver. The
amd-pstate driver has two approaches to implement the frequency control
behavior. That depends on the CPU hardware implementation. One is "Full
MSR Support" and another is "Shared Memory Support". The feature flag
indicates the current processors with "Full MSR Support".
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
arch/x86/include/asm/cpufeatures.h | 1 +
1 file changed, 1 insertion(+)
From: Mario Limonciello <mario.limonciello@amd.com>
As this is a static check, it should be based upon what is currently
present on the system. This makes probeing more deterministic.
While local APIC flags field (lapic_flags) of cpu core in MADT table is
0, then the cpu core won't be enabled. In this case, _CPC won't be found
in this core, and return back to _CPC invalid with walking through
possible cpus (include disable cpus). This is not expected, so switch to
check online CPUs instead.
Reported-by: Jinzhou Su <redacted>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
drivers/acpi/cppc_acpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Jinzhou Su <redacted>
Add a new function to enable CPPC feature. This function
will write Continuous Performance Control package
EnableRegister field on the processor.
Signed-off-by: Jinzhou Su <redacted>
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
drivers/acpi/cppc_acpi.c | 48 ++++++++++++++++++++++++++++++++++++++++
include/acpi/cppc_acpi.h | 5 +++++
2 files changed, 53 insertions(+)
@@ -1220,6 +1220,54 @@ int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs)}EXPORT_SYMBOL_GPL(cppc_get_perf_ctrs);+/**+*cppc_set_enable-SettoenableCPPContheprocessorbywritingthe+*ContinuousPerformanceControlpackageEnableRegisterfeild.+*@cpu:CPUforwhichtoenableCPPCregister.+*@enable:0-disable,1-enableCPPCfeatureontheprocessor.+*+*Return:0forsuccess,-ERRNOor-EIOotherwise.+*/+intcppc_set_enable(intcpu,u32enable)+{+intpcc_ss_id=per_cpu(cpu_pcc_subspace_idx,cpu);+structcpc_register_resource*enable_reg;+structcpc_desc*cpc_desc=per_cpu(cpc_desc_ptr,cpu);+structcppc_pcc_data*pcc_ss_data=NULL;+intret=-1;++/* check the input value*/+if(cpu<0||cpu>num_possible_cpus()-1||enable>1)+return-ENODEV;++if(!cpc_desc){+pr_debug("No CPC descriptor for CPU:%d\n",cpu);+return-ENODEV;+}++enable_reg=&cpc_desc->cpc_regs[ENABLE];++if(CPC_IN_PCC(enable_reg)){++if(pcc_ss_id<0)+return-EIO;++ret=cpc_write(cpu,enable_reg,enable);+if(ret)+returnret;++pcc_ss_data=pcc_data[pcc_ss_id];++down_write(&pcc_ss_data->pcc_lock);+/* after writing CPC, transfer the ownership of PCC to platfrom */+ret=send_pcc_cmd(pcc_ss_id,CMD_WRITE);+up_write(&pcc_ss_data->pcc_lock);+}++returnret;+}+EXPORT_SYMBOL_GPL(cppc_set_enable);+/***cppc_set_perf-SetaCPU'sperformancecontrols.*@cpu:CPUforwhichtosetperformancecontrols.
Introduce the fast switch function for amd-pstate module on the AMD
processors which support the full MSR register control. It's able to
decrease the lattency on interrupt context.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
drivers/cpufreq/amd-pstate.c | 38 ++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
@@ -195,6 +195,41 @@ static int amd_pstate_target(struct cpufreq_policy *policy,return0;}+staticvoidamd_pstate_adjust_perf(unsignedintcpu,+unsignedlongmin_perf,+unsignedlongtarget_perf,+unsignedlongcapacity)+{+unsignedlongamd_max_perf,amd_min_perf,amd_des_perf,+amd_cap_perf,lowest_nonlinear_perf;+structcpufreq_policy*policy=cpufreq_cpu_get(cpu);+structamd_cpudata*cpudata=policy->driver_data;++amd_cap_perf=READ_ONCE(cpudata->highest_perf);+lowest_nonlinear_perf=READ_ONCE(cpudata->lowest_nonlinear_perf);++if(target_perf<capacity)+amd_des_perf=DIV_ROUND_UP(amd_cap_perf*target_perf,+capacity);++amd_min_perf=READ_ONCE(cpudata->highest_perf);+if(min_perf<capacity)+amd_min_perf=DIV_ROUND_UP(amd_cap_perf*min_perf,capacity);++if(amd_min_perf<lowest_nonlinear_perf)+amd_min_perf=lowest_nonlinear_perf;++amd_max_perf=amd_cap_perf;+if(amd_max_perf<amd_min_perf)+amd_max_perf=amd_min_perf;++amd_des_perf=clamp_t(unsignedlong,amd_des_perf,+amd_min_perf,amd_max_perf);++amd_pstate_update(cpudata,amd_min_perf,amd_des_perf,+amd_max_perf,true);+}+staticintamd_get_min_freq(structamd_cpudata*cpudata){structcppc_perf_capscppc_perf;
@@ -333,6 +368,8 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)/* It will be updated by governor */policy->cur=policy->cpuinfo.min_freq;+policy->fast_switch_possible=true;+ret=freq_qos_add_request(&policy->constraints,&cpudata->req[0],FREQ_QOS_MIN,policy->cpuinfo.min_freq);if(ret<0){
amd-pstate is the AMD CPU performance scaling driver that introduces a
new CPU frequency control mechanism on AMD Zen based CPU series in Linux
kernel. The new mechanism is based on Collaborative processor
performance control (CPPC) which is finer grain frequency management
than legacy ACPI hardware P-States. Current AMD CPU platforms are using
the ACPI P-states driver to manage CPU frequency and clocks with
switching only in 3 P-states. AMD P-States is to replace the ACPI
P-states controls, allows a flexible, low-latency interface for the
Linux kernel to directly communicate the performance hints to hardware.
"amd-pstate" leverages the Linux kernel governors such as *schedutil*,
*ondemand*, etc. to manage the performance hints which are provided by CPPC
hardware functionality. The first version for amd-pstate is to support one
of the Zen3 processors, and we will support more in future after we verify
the hardware and SBIOS functionalities.
There are two types of hardware implementations for amd-pstate: one is full
MSR support and another is shared memory support. It can use
X86_FEATURE_AMD_CPPC_EXT feature flag to distinguish the different types.
Using the new AMD P-States method + kernel governors (*schedutil*,
*ondemand*, ...) to manage the frequency update is the most appropriate
bridge between AMD Zen based hardware processor and Linux kernel, the
processor is able to ajust to the most efficiency frequency according to
the kernel scheduler loading.
Performance Per Watt (PPW) Caculation:
The PPW caculation is referred by below paper:
https://software.intel.com/content/dam/develop/external/us/en/documents/performance-per-what-paper.pdf
Below formula is referred from below spec to measure the PPW:
(F / t) / P = F * t / (t * E) = F / E,
"F" is the number of frames per second.
"P" is power measurd in watts.
"E" is energy measured in joules.
We use the RAPL interface with "perf" tool to get the energy data of the
package power.
The data comparsions between amd-pstate and acpi-freq module are tested on
AMD Cezanne processor:
1) TBench CPU benchmark:
+---------------------------------------------------------------------+
| |
| TBench (Performance Per Watt) |
| Higher is better |
+-------------------+------------------------+------------------------+
| | Performance Per Watt | Performance Per Watt |
| Kernel Module | (Schedutil) | (Ondemand) |
| | Unit: MB / (s * J) | Unit: MB / (s * J) |
+-------------------+------------------------+------------------------+
| | | |
| acpi-cpufreq | 3.022 | 2.969 |
| | | |
+-------------------+------------------------+------------------------+
| | | |
| amd-pstate | 3.131 | 3.284 |
| | | |
+-------------------+------------------------+------------------------+
2) Gitsource CPU benchmark:
+---------------------------------------------------------------------+
| |
| Gitsource (Performance Per Watt) |
| Higher is better |
+-------------------+------------------------+------------------------+
| | Performance Per Watt | Performance Per Watt |
| Kernel Module | (Schedutil) | (Ondemand) |
| | Unit: 1 / (s * J) | Unit: 1 / (s * J) |
+-------------------+------------------------+------------------------+
| | | |
| acpi-cpufreq | 3.42172E-07 | 2.74508E-07 |
| | | |
+-------------------+------------------------+------------------------+
| | | |
| amd-pstate | 4.09141E-07 | 3.47610E-07 |
| | | |
+-------------------+------------------------+------------------------+
3) Speedometer 2.0 CPU benchmark:
+---------------------------------------------------------------------+
| |
| Speedometer 2.0 (Performance Per Watt) |
| Higher is better |
+-------------------+------------------------+------------------------+
| | Performance Per Watt | Performance Per Watt |
| Kernel Module | (Schedutil) | (Ondemand) |
| | Unit: 1 / (s * J) | Unit: 1 / (s * J) |
+-------------------+------------------------+------------------------+
| | | |
| acpi-cpufreq | 0.116111767 | 0.110321664 |
| | | |
+-------------------+------------------------+------------------------+
| | | |
| amd-pstate | 0.115825281 | 0.122024299 |
| | | |
+-------------------+------------------------+------------------------+
According to above average data, we can see this solution has shown better
performance per watt scaling on mobile CPU benchmarks in most of cases.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
drivers/cpufreq/Kconfig.x86 | 13 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/amd-pstate.c | 446 +++++++++++++++++++++++++++++++++++
3 files changed, 460 insertions(+)
create mode 100644 drivers/cpufreq/amd-pstate.c
@@ -0,0 +1,446 @@+// SPDX-License-Identifier: GPL-2.0-or-later+/*+*amd-pstate.c-AMDProcessorP-stateFrequencyDriver+*+*Copyright(C)2021AdvancedMicroDevices,Inc.AllRightsReserved.+*+*Thisprogramisfreesoftware;youcanredistributeitand/or+*modifyitunderthetermsoftheGNUGeneralPublicLicense+*aspublishedbytheFreeSoftwareFoundation;eitherversion2+*oftheLicense,or(atyouroption)anylaterversion.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*+*YoushouldhavereceivedacopyoftheGNUGeneralPublicLicensealongwith+*thisprogram;ifnot,writetotheFreeSoftware+*Foundation,Inc.,51FranklinStreet,FifthFloor,Boston,MA02110-1301,USA.+*+*Author:HuangRui<ray.huang@amd.com>+*/++#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt++#include<linux/kernel.h>+#include<linux/module.h>+#include<linux/init.h>+#include<linux/smp.h>+#include<linux/sched.h>+#include<linux/cpufreq.h>+#include<linux/compiler.h>+#include<linux/dmi.h>+#include<linux/slab.h>+#include<linux/acpi.h>+#include<linux/io.h>+#include<linux/delay.h>+#include<linux/uaccess.h>+#include<linux/static_call.h>++#include<acpi/processor.h>+#include<acpi/cppc_acpi.h>++#include<asm/msr.h>+#include<asm/processor.h>+#include<asm/cpufeature.h>+#include<asm/cpu_device_id.h>++#define AMD_PSTATE_TRANSITION_LATENCY 0x20000+#define AMD_PSTATE_TRANSITION_DELAY 500++staticstructcpufreq_driveramd_pstate_driver;++structamd_cpudata{+intcpu;++structfreq_qos_requestreq[2];+structcpufreq_policy*policy;++u64cppc_req_cached;++u32highest_perf;+u32nominal_perf;+u32lowest_nonlinear_perf;+u32lowest_perf;++u32max_freq;+u32min_freq;+u32nominal_freq;+u32lowest_nonlinear_freq;+};++staticinlineintpstate_enable(boolenable)+{+returnwrmsrl_safe(MSR_AMD_CPPC_ENABLE,enable?1:0);+}++DEFINE_STATIC_CALL(amd_pstate_enable,pstate_enable);++staticinlineintamd_pstate_enable(boolenable)+{+returnstatic_call(amd_pstate_enable)(enable);+}++staticintpstate_init_perf(structamd_cpudata*cpudata)+{+u64cap1;++intret=rdmsrl_safe_on_cpu(cpudata->cpu,MSR_AMD_CPPC_CAP1,+&cap1);+if(ret)+returnret;++/*+*TODO:IntroduceAMDspecificpowerfeature.+*+*CPPCentrydoesn'tindicatethehighestperformanceinsomeASICs.+*/+WRITE_ONCE(cpudata->highest_perf,amd_get_highest_perf());++WRITE_ONCE(cpudata->nominal_perf,CAP1_NOMINAL_PERF(cap1));+WRITE_ONCE(cpudata->lowest_nonlinear_perf,CAP1_LOWNONLIN_PERF(cap1));+WRITE_ONCE(cpudata->lowest_perf,CAP1_LOWEST_PERF(cap1));++return0;+}++DEFINE_STATIC_CALL(amd_pstate_init_perf,pstate_init_perf);++staticinlineintamd_pstate_init_perf(structamd_cpudata*cpudata)+{+returnstatic_call(amd_pstate_init_perf)(cpudata);+}++staticvoidpstate_update_perf(structamd_cpudata*cpudata,u32min_perf,+u32des_perf,u32max_perf,+boolfast_switch)+{+if(fast_switch)+wrmsrl(MSR_AMD_CPPC_REQ,READ_ONCE(cpudata->cppc_req_cached));+else+wrmsrl_on_cpu(cpudata->cpu,MSR_AMD_CPPC_REQ,+READ_ONCE(cpudata->cppc_req_cached));+}++DEFINE_STATIC_CALL(amd_pstate_update_perf,pstate_update_perf);++staticinlinevoid+amd_pstate_update_perf(structamd_cpudata*cpudata,u32min_perf,+u32des_perf,u32max_perf,boolfast_switch)+{+static_call(amd_pstate_update_perf)(cpudata,min_perf,des_perf,+max_perf,fast_switch);+}++staticvoid+amd_pstate_update(structamd_cpudata*cpudata,u32min_perf,+u32des_perf,u32max_perf,boolfast_switch)+{+u64prev=READ_ONCE(cpudata->cppc_req_cached);+u64value=prev;++value&=~REQ_MIN_PERF(~0L);+value|=REQ_MIN_PERF(min_perf);++value&=~REQ_DES_PERF(~0L);+value|=REQ_DES_PERF(des_perf);++value&=~REQ_MAX_PERF(~0L);+value|=REQ_MAX_PERF(max_perf);++if(value==prev)+return;++WRITE_ONCE(cpudata->cppc_req_cached,value);++amd_pstate_update_perf(cpudata,min_perf,des_perf,+max_perf,fast_switch);+}++staticintamd_pstate_verify(structcpufreq_policy_data*policy)+{+cpufreq_verify_within_cpu_limits(policy);++return0;+}++staticintamd_pstate_target(structcpufreq_policy*policy,+unsignedinttarget_freq,+unsignedintrelation)+{+structcpufreq_freqsfreqs;+structamd_cpudata*cpudata=policy->driver_data;+unsignedlongamd_max_perf,amd_min_perf,amd_des_perf,+amd_cap_perf;++if(!cpudata->max_freq)+return-ENODEV;++amd_cap_perf=READ_ONCE(cpudata->highest_perf);+amd_min_perf=READ_ONCE(cpudata->lowest_nonlinear_perf);+amd_max_perf=amd_cap_perf;++freqs.old=policy->cur;+freqs.new=target_freq;++amd_des_perf=DIV_ROUND_CLOSEST(target_freq*amd_cap_perf,+cpudata->max_freq);++cpufreq_freq_transition_begin(policy,&freqs);+amd_pstate_update(cpudata,amd_min_perf,amd_des_perf,+amd_max_perf,false);+cpufreq_freq_transition_end(policy,&freqs,false);++return0;+}++staticintamd_get_min_freq(structamd_cpudata*cpudata)+{+structcppc_perf_capscppc_perf;++intret=cppc_get_perf_caps(cpudata->cpu,&cppc_perf);+if(ret)+returnret;++/* Switch to khz */+returncppc_perf.lowest_freq*1000;+}++staticintamd_get_max_freq(structamd_cpudata*cpudata)+{+structcppc_perf_capscppc_perf;+u32max_perf,max_freq,nominal_freq,nominal_perf;+u64boost_ratio;++intret=cppc_get_perf_caps(cpudata->cpu,&cppc_perf);+if(ret)+returnret;++nominal_freq=cppc_perf.nominal_freq;+nominal_perf=READ_ONCE(cpudata->nominal_perf);+max_perf=READ_ONCE(cpudata->highest_perf);++boost_ratio=div_u64(max_perf<<SCHED_CAPACITY_SHIFT,+nominal_perf);++max_freq=nominal_freq*boost_ratio>>SCHED_CAPACITY_SHIFT;++/* Switch to khz */+returnmax_freq*1000;+}++staticintamd_get_nominal_freq(structamd_cpudata*cpudata)+{+structcppc_perf_capscppc_perf;+u32nominal_freq;++intret=cppc_get_perf_caps(cpudata->cpu,&cppc_perf);+if(ret)+returnret;++nominal_freq=cppc_perf.nominal_freq;++/* Switch to khz */+returnnominal_freq*1000;+}++staticintamd_get_lowest_nonlinear_freq(structamd_cpudata*cpudata)+{+structcppc_perf_capscppc_perf;+u32lowest_nonlinear_freq,lowest_nonlinear_perf,+nominal_freq,nominal_perf;+u64lowest_nonlinear_ratio;++intret=cppc_get_perf_caps(cpudata->cpu,&cppc_perf);+if(ret)+returnret;++nominal_freq=cppc_perf.nominal_freq;+nominal_perf=READ_ONCE(cpudata->nominal_perf);++lowest_nonlinear_perf=cppc_perf.lowest_nonlinear_perf;++lowest_nonlinear_ratio=div_u64(lowest_nonlinear_perf<<+SCHED_CAPACITY_SHIFT,nominal_perf);++lowest_nonlinear_freq=nominal_freq*lowest_nonlinear_ratio>>SCHED_CAPACITY_SHIFT;++/* Switch to khz */+returnlowest_nonlinear_freq*1000;+}++staticintamd_pstate_init_freqs_in_cpudata(structamd_cpudata*cpudata,+u32max_freq,u32min_freq,+u32nominal_freq,+u32lowest_nonlinear_freq)+{+if(!cpudata)+return-EINVAL;++/* Initial processor data capability frequencies */+cpudata->max_freq=max_freq;+cpudata->min_freq=min_freq;+cpudata->nominal_freq=nominal_freq;+cpudata->lowest_nonlinear_freq=lowest_nonlinear_freq;++return0;+}++staticintamd_pstate_cpu_init(structcpufreq_policy*policy)+{+intmin_freq,max_freq,nominal_freq,lowest_nonlinear_freq,ret;+unsignedintcpu=policy->cpu;+structdevice*dev;+structamd_cpudata*cpudata;++dev=get_cpu_device(policy->cpu);+if(!dev)+return-ENODEV;++cpudata=kzalloc(sizeof(*cpudata),GFP_KERNEL);+if(!cpudata)+return-ENOMEM;++cpudata->cpu=cpu;+cpudata->policy=policy;++ret=amd_pstate_init_perf(cpudata);+if(ret)+gotofree_cpudata1;++min_freq=amd_get_min_freq(cpudata);+max_freq=amd_get_max_freq(cpudata);+nominal_freq=amd_get_nominal_freq(cpudata);+lowest_nonlinear_freq=amd_get_lowest_nonlinear_freq(cpudata);++if(min_freq<0||max_freq<0||min_freq>max_freq){+dev_err(dev,"min_freq(%d) or max_freq(%d) value is incorrect\n",+min_freq,max_freq);+ret=-EINVAL;+gotofree_cpudata1;+}++policy->cpuinfo.transition_latency=AMD_PSTATE_TRANSITION_LATENCY;+policy->transition_delay_us=AMD_PSTATE_TRANSITION_DELAY;++policy->min=min_freq;+policy->max=max_freq;++policy->cpuinfo.min_freq=min_freq;+policy->cpuinfo.max_freq=max_freq;++/* It will be updated by governor */+policy->cur=policy->cpuinfo.min_freq;++ret=freq_qos_add_request(&policy->constraints,&cpudata->req[0],+FREQ_QOS_MIN,policy->cpuinfo.min_freq);+if(ret<0){+dev_err(dev,"Failed to add min-freq constraint (%d)\n",ret);+gotofree_cpudata1;+}++ret=freq_qos_add_request(&policy->constraints,&cpudata->req[1],+FREQ_QOS_MAX,policy->cpuinfo.max_freq);+if(ret<0){+dev_err(dev,"Failed to add max-freq constraint (%d)\n",ret);+gotofree_cpudata2;+}++ret=amd_pstate_init_freqs_in_cpudata(cpudata,max_freq,min_freq,+nominal_freq,+lowest_nonlinear_freq);+if(ret){+dev_err(dev,"Failed to init cpudata (%d)\n",ret);+gotofree_cpudata3;+}++policy->driver_data=cpudata;++return0;++free_cpudata3:+freq_qos_remove_request(&cpudata->req[1]);+free_cpudata2:+freq_qos_remove_request(&cpudata->req[0]);+free_cpudata1:+kfree(cpudata);+returnret;+}++staticintamd_pstate_cpu_exit(structcpufreq_policy*policy)+{+structamd_cpudata*cpudata;++cpudata=policy->driver_data;++freq_qos_remove_request(&cpudata->req[1]);+freq_qos_remove_request(&cpudata->req[0]);+kfree(cpudata);++return0;+}++staticstructcpufreq_driveramd_pstate_driver={+.flags=CPUFREQ_CONST_LOOPS|CPUFREQ_NEED_UPDATE_LIMITS,+.verify=amd_pstate_verify,+.target=amd_pstate_target,+.init=amd_pstate_cpu_init,+.exit=amd_pstate_cpu_exit,+.name="amd-pstate",+};++staticint__initamd_pstate_init(void)+{+intret;++if(boot_cpu_data.x86_vendor!=X86_VENDOR_AMD)+return-ENODEV;++if(!acpi_cpc_valid()){+pr_debug("%s, the _CPC object is not present in SBIOS\n",+__func__);+return-ENODEV;+}++/* don't keep reloading if cpufreq_driver exists */+if(cpufreq_get_current_driver())+return-EEXIST;++/* capability check */+if(!boot_cpu_has(X86_FEATURE_AMD_CPPC)){+pr_debug("%s, AMD CPPC MSR based functionality is not supported\n",+__func__);+return-ENODEV;+}++/* enable amd pstate feature */+ret=amd_pstate_enable(true);+if(ret){+pr_err("%s, failed to enable amd-pstate with return %d\n",+__func__,ret);+returnret;+}++ret=cpufreq_register_driver(&amd_pstate_driver);+if(ret){+pr_err("%s, return %d\n",__func__,ret);+returnret;+}++return0;+}++staticvoid__exitamd_pstate_exit(void)+{+cpufreq_unregister_driver(&amd_pstate_driver);++amd_pstate_enable(false);+}++module_init(amd_pstate_init);+module_exit(amd_pstate_exit);++MODULE_AUTHOR("Huang Rui <ray.huang@amd.com>");+MODULE_DESCRIPTION("AMD Processor P-state Frequency Driver");+MODULE_LICENSE("GPL");
In some old Zen based processors, they are using the shared memory that
exposed from ACPI SBIOS.
Signed-off-by: Jinzhou Su <redacted>
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
drivers/cpufreq/amd-pstate.c | 58 ++++++++++++++++++++++++++++++++----
1 file changed, 53 insertions(+), 5 deletions(-)
@@ -368,7 +412,8 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)/* It will be updated by governor */policy->cur=policy->cpuinfo.min_freq;-policy->fast_switch_possible=true;+if(boot_cpu_has(X86_FEATURE_AMD_CPPC))+policy->fast_switch_possible=true;ret=freq_qos_add_request(&policy->constraints,&cpudata->req[0],FREQ_QOS_MIN,policy->cpuinfo.min_freq);
@@ -17,6 +17,10 @@ obj-$(CONFIG_CPU_FREQ_GOV_ATTR_SET) += cpufreq_governor_attr_set.oobj-$(CONFIG_CPUFREQ_DT)+=cpufreq-dt.oobj-$(CONFIG_CPUFREQ_DT_PLATDEV)+=cpufreq-dt-platdev.o+# Traces+CFLAGS_amd-pstate-trace.o:=-I$(src)+amd_pstate-y:=amd-pstate.oamd-pstate-trace.o+################################################################################### x86 drivers.# Link order matters. K8 is preferred to ACPI because of firmware bugs in early
@@ -25,7 +29,7 @@ obj-$(CONFIG_CPUFREQ_DT_PLATDEV) += cpufreq-dt-platdev.o# speedstep-* is preferred over p4-clockmod.obj-$(CONFIG_X86_ACPI_CPUFREQ)+=acpi-cpufreq.o-obj-$(CONFIG_X86_AMD_PSTATE)+=amd-pstate.o+obj-$(CONFIG_X86_AMD_PSTATE)+=amd_pstate.oobj-$(CONFIG_X86_POWERNOW_K8)+=powernow-k8.oobj-$(CONFIG_X86_PCC_CPUFREQ)+=pcc-cpufreq.oobj-$(CONFIG_X86_POWERNOW_K6)+=powernow-k6.o
The amd-pstate hardware support check will be needed by cpupower to know
whether amd-pstate is enabled and supported.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
drivers/cpufreq/amd-pstate.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
If the sbios supports the boost mode of amd-pstate, let's switch to
boost enabled by default.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
drivers/cpufreq/amd-pstate.c | 44 ++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
@@ -360,6 +362,45 @@ static int amd_get_lowest_nonlinear_freq(struct amd_cpudata *cpudata)returnlowest_nonlinear_freq*1000;}+staticintamd_pstate_set_boost(structcpufreq_policy*policy,intstate)+{+structamd_cpudata*cpudata=policy->driver_data;+intret;++if(!cpudata->boost_supported){+pr_err("Boost mode is not supported by this processor or SBIOS\n");+return-EINVAL;+}++if(state)+policy->cpuinfo.max_freq=cpudata->max_freq;+else+policy->cpuinfo.max_freq=cpudata->nominal_freq;++policy->max=policy->cpuinfo.max_freq;++ret=freq_qos_update_request(&cpudata->req[1],+policy->cpuinfo.max_freq);+if(ret<0)+returnret;++return0;+}++staticvoidamd_pstate_boost_init(structamd_cpudata*cpudata)+{+u32highest_perf,nominal_perf;++highest_perf=READ_ONCE(cpudata->highest_perf);+nominal_perf=READ_ONCE(cpudata->nominal_perf);++if(highest_perf<=nominal_perf)+return;++cpudata->boost_supported=true;+amd_pstate_driver.boost_enabled=true;+}+staticintamd_pstate_init_freqs_in_cpudata(structamd_cpudata*cpudata,u32max_freq,u32min_freq,u32nominal_freq,
@@ -450,6 +491,8 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)policy->driver_data=cpudata;+amd_pstate_boost_init(cpudata);+return0;free_cpudata3:
The processor with amd-pstate function also supports legacy ACPI
hardware P-States feature as well. Once driver sets amd-pstate eanbled,
the processor will respond the finer grain amd-pstate feature instead of
legacy ACPI P-States. So it introduces the cpupower_amd_pstate_enabled()
to check whether the current kernel enables amd-pstate or acpi-cpufreq
module.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
tools/power/cpupower/utils/helpers/helpers.h | 9 +++++++++
tools/power/cpupower/utils/helpers/misc.c | 20 ++++++++++++++++++++
2 files changed, 29 insertions(+)
@@ -136,6 +136,12 @@ extern int decode_pstates(unsigned int cpu, int boost_states,externintcpufreq_has_boost_support(unsignedintcpu,int*support,int*active,int*states);++/* AMD P-States stuff **************************/+externunsignedlongcpupower_amd_pstate_enabled(void);++/* AMD P-States stuff **************************/+/**CPUIDfunctionsreturningasingledatum*/
@@ -168,6 +174,9 @@ static inline int cpufreq_has_boost_support(unsigned int cpu, int *support,int*active,int*states){return-1;}+staticinlineunsignedlongcpupower_amd_pstate_enabled(void)+{return0;}+/* cpuid and cpuinfo helpers **************************/staticinlineunsignedintcpuid_eax(unsignedintop){return0;};
If kernel starts the amd-pstate module, the cpupower will initial the
capability flag as CPUPOWER_CAP_AMD_PSTATE. And once amd-pstate
capability is set, it won't need to set legacy ACPI relative
capabilities anymore.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
tools/power/cpupower/utils/helpers/cpuid.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
Introduce the marco definitions and access helper function for
amd-pstate sysfs interfaces such as each performance goals and frequency
levels in amd helper file. They will be used to read the sysfs attribute
from amd-pstate cpufreq driver for cpupower utilities.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
tools/power/cpupower/utils/helpers/amd.c | 39 ++++++++++++++++++++++++
1 file changed, 39 insertions(+)
Expose the helper into cpufreq header, then cpufreq driver can use this
function to get the sysfs value if it has any specific sysfs interfaces.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
tools/power/cpupower/lib/cpufreq.c | 21 +++++++++++++++------
tools/power/cpupower/lib/cpufreq.h | 12 ++++++++++++
2 files changed, 27 insertions(+), 6 deletions(-)
@@ -109,6 +110,14 @@ static unsigned long sysfs_cpufreq_get_one_value(unsigned int cpu,returnvalue;}+staticunsignedlongsysfs_cpufreq_get_one_value(unsignedintcpu,+enumcpufreq_valuewhich)+{+returncpufreq_get_sysfs_value_from_table(cpu,cpufreq_value_files,+which,+MAX_CPUFREQ_VALUE_READ_FILES);+}+/* read access to files which contain one string */enumcpufreq_string{
The legacy ACPI hardware P-States function has 3 P-States on ACPI table,
the CPU frequency only can be switched between the 3 P-States. While the
processor supports the boost state, it will have another boost state
that the frequency can be higher than P0 state, and the state can be
decoded by the function of decode_pstates() and read by
amd_pci_get_num_boost_states().
However, the new AMD P-States function is different than legacy ACPI
hardware P-State on AMD processors. That has a finer grain frequency
range between the highest and lowest frequency. And boost frequency is
actually the frequency which is mapped on highest performance ratio. The
similiar previous P0 frequency is mapped on nominal performance ratio.
If the highest performance on the processor is higher than nominal
performance, then we think the current processor supports the boost
state. And it uses amd_pstate_boost_init() to initialize boost for AMD
P-States function.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
tools/power/cpupower/utils/helpers/amd.c | 18 ++++++++++++++++++
tools/power/cpupower/utils/helpers/helpers.h | 5 +++++
tools/power/cpupower/utils/helpers/misc.c | 2 ++
3 files changed, 25 insertions(+)
@@ -139,6 +139,8 @@ extern int cpufreq_has_boost_support(unsigned int cpu, int *support,/* AMD P-States stuff **************************/externunsignedlongcpupower_amd_pstate_enabled(void);+externvoidamd_pstate_boost_init(unsignedintcpu,+int*support,int*active);/* AMD P-States stuff **************************/
@@ -176,6 +178,9 @@ static inline int cpufreq_has_boost_support(unsigned int cpu, int *support,staticinlineunsignedlongcpupower_amd_pstate_enabled(void){return0;}+staticvoidamd_pstate_boost_init(unsignedintcpu,+int*support,int*active)+{return;}/* cpuid and cpuinfo helpers **************************/
@@ -39,6 +39,8 @@ int cpufreq_has_boost_support(unsigned int cpu, int *support, int *active,if(ret)returnret;}+}elseif(cpupower_cpu_info.caps&CPUPOWER_CAP_AMD_PSTATE){+amd_pstate_boost_init(cpu,support,active);}elseif(cpupower_cpu_info.caps&CPUPOWER_CAP_INTEL_IDA)*support=*active=1;return0;
The print_speed can be as a common function, and expose it into misc
helper header. Then it can be used on other helper files as well.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
tools/power/cpupower/utils/cpufreq-info.c | 59 ++++----------------
tools/power/cpupower/utils/helpers/helpers.h | 1 +
tools/power/cpupower/utils/helpers/misc.c | 42 ++++++++++++++
3 files changed, 54 insertions(+), 48 deletions(-)
@@ -254,11 +217,11 @@ static int get_boost_mode(unsigned int cpu)if(freqs){printf(_(" boost frequency steps: "));while(freqs->next){-print_speed(freqs->frequency);+print_speed(freqs->frequency,no_rounding);printf(", ");freqs=freqs->next;}-print_speed(freqs->frequency);+print_speed(freqs->frequency,no_rounding);printf("\n");cpufreq_put_available_frequencies(freqs);}
@@ -277,7 +240,7 @@ static int get_freq_kernel(unsigned int cpu, unsigned int human)return-EINVAL;}if(human){-print_speed(freq);+print_speed(freq,no_rounding);}elseprintf("%lu",freq);printf(_(" (asserted by call to kernel)\n"));
@@ -296,7 +259,7 @@ static int get_freq_hardware(unsigned int cpu, unsigned int human)return-EINVAL;}if(human){-print_speed(freq);+print_speed(freq,no_rounding);}elseprintf("%lu",freq);printf(_(" (asserted by call to hardware)\n"));
@@ -316,9 +279,9 @@ static int get_hardware_limits(unsigned int cpu, unsigned int human)if(human){printf(_(" hardware limits: "));-print_speed(min);+print_speed(min,no_rounding);printf(" - ");-print_speed(max);+print_speed(max,no_rounding);printf("\n");}else{printf("%lu %lu\n",min,max);
@@ -350,9 +313,9 @@ static int get_policy(unsigned int cpu)return-EINVAL;}printf(_(" current policy: frequency should be within "));-print_speed(policy->min);+print_speed(policy->min,no_rounding);printf(_(" and "));-print_speed(policy->max);+print_speed(policy->max,no_rounding);printf(".\n ");printf(_("The governor \"%s\" may decide which speed to use\n"
@@ -436,7 +399,7 @@ static int get_freq_stats(unsigned int cpu, unsigned int human)structcpufreq_stats*stats=cpufreq_get_stats(cpu,&total_time);while(stats){if(human){-print_speed(stats->frequency);+print_speed(stats->frequency,no_rounding);printf(":%.2f%%",(100.0*stats->time_in_state)/total_time);}else
@@ -486,11 +449,11 @@ static void debug_output_one(unsigned int cpu)if(freqs){printf(_(" available frequency steps: "));while(freqs->next){-print_speed(freqs->frequency);+print_speed(freqs->frequency,no_rounding);printf(", ");freqs=freqs->next;}-print_speed(freqs->frequency);+print_speed(freqs->frequency,no_rounding);printf("\n");cpufreq_put_available_frequencies(freqs);}
@@ -166,3 +166,45 @@ void print_offline_cpus(void)printf(_("cpupower set operation was not performed on them\n"));}}++/*+*print_speed+*+*PrinttheexactCPUfrequencywithappropriateunit+*/+voidprint_speed(unsignedlongspeed,intno_rounding)+{+unsignedlongtmp;++if(no_rounding){+if(speed>1000000)+printf("%u.%06u GHz",((unsignedint)speed/1000000),+((unsignedint)speed%1000000));+elseif(speed>1000)+printf("%u.%03u MHz",((unsignedint)speed/1000),+(unsignedint)(speed%1000));+else+printf("%lu kHz",speed);+}else{+if(speed>1000000){+tmp=speed%10000;+if(tmp>=5000)+speed+=10000;+printf("%u.%02u GHz",((unsignedint)speed/1000000),+((unsignedint)(speed%1000000)/10000));+}elseif(speed>100000){+tmp=speed%1000;+if(tmp>=500)+speed+=1000;+printf("%u MHz",((unsignedint)speed/1000));+}elseif(speed>1000){+tmp=speed%100;+if(tmp>=50)+speed+=100;+printf("%u.%01u MHz",((unsignedint)speed/1000),+((unsignedint)(speed%1000)/100));+}+}++return;+}
amd-pstate kernel module is using the fine grain frequency instead of
acpi hardware pstate. So the performance and frequency values should be
printed in frequency-info.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
tools/power/cpupower/utils/cpufreq-info.c | 9 ++++---
tools/power/cpupower/utils/helpers/amd.c | 25 ++++++++++++++++++++
tools/power/cpupower/utils/helpers/helpers.h | 5 ++++
3 files changed, 36 insertions(+), 3 deletions(-)
@@ -141,6 +141,8 @@ extern int cpufreq_has_boost_support(unsigned int cpu, int *support,externunsignedlongcpupower_amd_pstate_enabled(void);externvoidamd_pstate_boost_init(unsignedintcpu,int*support,int*active);+externvoidamd_pstate_show_perf_and_freq(unsignedintcpu,+intno_rounding);/* AMD P-States stuff **************************/
@@ -181,6 +183,9 @@ static inline unsigned long cpupower_amd_pstate_enabled(void)staticvoidamd_pstate_boost_init(unsignedintcpu,int*support,int*active){return;}+staticinlinevoidamd_pstate_show_perf_and_freq(unsignedintcpu,+intno_rounding)+{return;}/* cpuid and cpuinfo helpers **************************/
@@ -0,0 +1,377 @@+.. SPDX-License-Identifier: GPL-2.0+..include::<isonum.txt>++===============================================+``amd-pstate`` CPU Performance Scaling Driver+===============================================++:Copyright: |copy| 2021 Advanced Micro Devices, Inc.++:Author: Huang Rui <ray.huang@amd.com>+++Introduction+===================++``amd-pstate`` is the AMD CPU performance scaling driver that introduces a+new CPU frequency control mechanism on modern AMD APU and CPU series in+Linux kernel. The new mechanism is based on Collaborative Processor+Performance Control (CPPC) which provides finer grain frequency management+than legacy ACPI hardware P-States. Current AMD CPU/APU platforms are using+the ACPI P-states driver to manage CPU frequency and clocks with switching+only in 3 P-states. CPPC replaces the ACPI P-states controls, allows a+flexible, low-latency interface for the Linux kernel to directly+communicate the performance hints to hardware.++``amd-pstate`` leverages the Linux kernel governors such as ``schedutil``,+``ondemand``, etc. to manage the performance hints which are provided by+CPPC hardware functionality that internally follows the hardware+specification (for details refer to AMD64 Architecture Programmer's Manual+Volume 2: System Programming [1]_). Currently ``amd-pstate`` supports basic+frequency control function according to kernel governors on some of the+Zen2 and Zen3 processors, and we will implement more AMD specific functions+in future after we verify them on the hardware and SBIOS.+++AMD CPPC Overview+=======================++Collaborative Processor Performance Control (CPPC) interface enumerates a+continuous, abstract, and unit-less performance value in a scale that is+not tied to a specific performance state / frequency. This is an ACPI+standard [2]_ which software can specify application performance goals and+hints as a relative target to the infrastructure limits. AMD processors+provides the low latency register model (MSR) instead of AML code+interpreter for performance adjustments. ``amd-pstate`` will initialize a+``struct cpufreq_driver`` instance ``amd_pstate_driver`` with the callbacks+to manage each performance update behavior. ::++ Highest Perf ------>+-----------------------+ +-----------------------++| | | |+| | | |+| | Max Perf ---->| |+| | | |+| | | |+ Nominal Perf ------>+-----------------------+ +-----------------------++| | | |+| | | |+| | | |+| | | |+| | | |+| | | |+| | Desired Perf ---->| |+| | | |+| | | |+| | | |+| | | |+| | | |+| | | |+| | | |+| | | |+| | | |+ Lowest non- | | | |+ linear perf ------>+-----------------------+ +-----------------------++| | | |+| | Lowest perf ---->| |+| | | |+ Lowest perf ------>+-----------------------+ +-----------------------++| | | |+| | | |+| | | |+ 0 ------>+-----------------------+ +-----------------------+++ AMD P-States Performance Scale+++.._perf_cap:++AMD CPPC Performance Capability+--------------------------------++Highest Performance (RO)+.........................++It is the absolute maximum performance an individual processor may reach,+assuming ideal conditions. This performance level may not be sustainable+for long durations and may only be achievable if other platform components+are in a specific state; for example, it may require other processors be in+an idle state. This would be equivalent to the highest frequencies+supported by the processor.++Nominal (Guaranteed) Performance (RO)+......................................++It is the maximum sustained performance level of the processor, assuming+ideal operating conditions. In absence of an external constraint (power,+thermal, etc.) this is the performance level the processor is expected to+be able to maintain continuously. All cores/processors are expected to be+able to sustain their nominal performance state simultaneously.++Lowest non-linear Performance (RO)+...................................++It is the lowest performance level at which nonlinear power savings are+achieved, for example, due to the combined effects of voltage and frequency+scaling. Above this threshold, lower performance levels should be generally+more energy efficient than higher performance levels. This register+effectively conveys the most efficient performance level to ``amd-pstate``.++Lowest Performance (RO)+........................++It is the absolute lowest performance level of the processor. Selecting a+performance level lower than the lowest nonlinear performance level may+cause an efficiency penalty but should reduce the instantaneous power+consumption of the processor.++AMD CPPC Performance Control+------------------------------++``amd-pstate`` passes performance goals through these registers. The+register drives the behavior of the desired performance target.++Minimum requested performance (RW)+...................................++``amd-pstate`` specifies the minimum allowed performance level.++Maximum requested performance (RW)+...................................++``amd-pstate`` specifies a limit the maximum performance that is expected+to be supplied by the hardware.++Desired performance target (RW)+...................................++``amd-pstate`` specifies a desired target in the CPPC performance scale as+a relative number. This can be expressed as percentage of nominal+performance (infrastructure max). Below the nominal sustained performance+level, desired performance expresses the average performance level of the+processor subject to hardware. Above the nominal performance level,+processor must provide at least nominal performance requested and go higher+if current operating conditions allow.++Energy Performance Preference (EPP) (RW)+.........................................++Provides a hint to the hardware if software wants to bias toward performance+(0x0) or energy efficiency (0xff).+++Key Governors Support+=======================++``amd-pstate`` can be used with all the (generic) scaling governors listed+by the ``scaling_available_governors`` policy attribute in ``sysfs``. Then,+it is responsible for the configuration of policy objects corresponding to+CPUs and provides the ``CPUFreq`` core (and the scaling governors attached+to the policy objects) with accurate information on the maximum and minimum+operating frequencies supported by the hardware. Users can check the+``scaling_cur_freq`` information comes from the ``CPUFreq`` core.++``amd-pstate`` mainly supports ``schedutil`` and ``ondemand`` for dynamic+frequency control. It is to fine tune the processor configuration on+``amd-pstate`` to the ``schedutil`` with CPU CFS scheduler. ``amd-pstate``+registers adjust_perf callback to implement the CPPC similar performance+update behavior. It is initialized by ``sugov_start`` and then populate the+CPU's update_util_data pointer to assign ``sugov_update_single_perf`` as+the utilization update callback function in CPU scheduler. CPU scheduler+will call ``cpufreq_update_util`` and assign the target performance+according to the ``struct sugov_cpu`` that utilization update belongs to.+Then ``amd-pstate`` updates the desired performance according to the CPU+scheduler assigned.+++Processor Support+=======================++The ``amd-pstate`` initialization will fail if the _CPC in ACPI SBIOS is+not existed at the detected processor, and it uses ``acpi_cpc_valid`` to+check the _CPC existence. All Zen based processors support legacy ACPI+hardware P-States function, so while the ``amd-pstate`` fails to be+initialized, the kernel will fall back to initialize ``acpi-cpufreq``+driver.++There are two types of hardware implementations for ``amd-pstate``: one is+`Full MSR Support <perf_cap_>`_ and another is `Shared Memory Support+<perf_cap_>`_. It can use :c:macro:`X86_FEATURE_AMD_CPPC_EXT` feature flag+(for details refer to Processor Programming Reference (PPR) for AMD Family+19h Model 21h, Revision B0 Processors [3]_) to indicate the different+types. ``amd-pstate`` is to register different ``amd_pstate_perf_funcs``+instances for different hardware implementations.++Currently, some of Zen2 and Zen3 processors support ``amd-pstate``. In the+future, it will be supported on more and more AMD processors.++Full MSR Support+-----------------++Some new Zen3 processors such as Cezanne provide the MSR registers directly+while the :c:macro:`X86_FEATURE_AMD_CPPC_EXT` CPU feature flag is set.+``amd-pstate`` can handle the MSR register to implement the fast switch+function in ``CPUFreq`` that can shrink latency of frequency control on the+interrupt context.++Shared Memory Support+----------------------++If :c:macro:`X86_FEATURE_AMD_CPPC_EXT` CPU feature flag is not set, that+means the processor supports shared memory solution. In this case,+``amd-pstate`` uses the ``cppc_acpi`` helper methods to implement the+callback functions of ``amd_pstate_perf_funcs``.+++AMD P-States and ACPI hardware P-States always can be supported in one+processor. But AMD P-States has the higher priority and if it is enabled+with :c:macro:`MSR_AMD_CPPC_ENABLE` or ``cppc_set_enable``, it will respond+to the request from AMD P-States.+++User Space Interface in ``sysfs``+==================================++``amd-pstate`` exposes several global attributes (files) in ``sysfs`` to+control its functionality at the system level. They located in the+``/sys/devices/system/cpu/cpufreq/policyX/`` directory and affect all CPUs. ::++ root@hr-test1:/home/ray# ls /sys/devices/system/cpu/cpufreq/policy0/*amd*+ /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_highest_perf+ /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_lowest_nonlinear_freq+ /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_lowest_nonlinear_perf+ /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_lowest_perf+ /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_max_freq+ /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_min_freq+ /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_nominal_freq+ /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_nominal_perf+ /sys/devices/system/cpu/cpufreq/policy0/is_amd_pstate_enabled+++``is_amd_pstate_enabled``++Query whether current kernel loads ``amd-pstate`` to enable the AMD+P-States functionality.+This attribute is read-only.++``amd_pstate_highest_perf / amd_pstate_max_freq``++Maximum CPPC performance and CPU frequency that the driver is allowed to+set in percent of the maximum supported CPPC performance level (the highest+performance supported in `AMD CPPC Performance Capability <perf_cap_>`_).+This attribute is read-only.++``amd_pstate_nominal_perf / amd_pstate_nominal_freq``++Nominal CPPC performance and CPU frequency that the driver is allowed to+set in percent of the maximum supported CPPC performance level (Please see+nominal performance in `AMD CPPC Performance Capability <perf_cap_>`_).+This attribute is read-only.++``amd_pstate_lowest_nonlinear_perf / amd_pstate_lowest_nonlinear_freq``++The lowest non-linear CPPC performance and CPU frequency that the driver is+allowed to set in percent of the maximum supported CPPC performance level+(Please see the lowest non-linear performance in `AMD CPPC Performance+Capability <perf_cap_>`_).+This attribute is read-only.++``amd_pstate_lowest_perf / amd_pstate_min_freq``++The lowest physical CPPC performance and CPU frequency.+This attribute is read-only.+++``amd-pstate`` vs ``acpi-cpufreq``+======================================++On majority of AMD platforms supported by ``acpi-cpufreq``, the ACPI tables+provided by the platform firmware used for CPU performance scaling, but+only provides 3 P-states on AMD processors.+However, on modern AMD APU and CPU series, it provides the collaborative+processor performance control according to ACPI protocol and customize this+for AMD platforms. That is fine-grain and continuous frequency range+instead of the legacy hardware P-states. ``amd-pstate`` is the kernel+module which supports the new AMD P-States mechanism on most of future AMD+platforms. The AMD P-States mechanism will be the more performance and energy+efficiency frequency management method on AMD processors.++``cpupower`` tool support for ``amd-pstate``+===============================================++``amd-pstate`` is supported on ``cpupower`` tool that can be used to dump the frequency+information. And it is in progress to support more and more operations for new+``amd-pstate`` module with this tool. ::++ root@hr-test1:/home/ray# cpupower frequency-info+ analyzing CPU 0:+ driver: amd-pstate+ CPUs which run at the same hardware frequency: 0+ CPUs which need to have their frequency coordinated by software: 0+ maximum transition latency: 131 us+ hardware limits: 400 MHz - 4.68 GHz+ available cpufreq governors: ondemand conservative powersave userspace performance schedutil+ current policy: frequency should be within 400 MHz and 4.68 GHz.+ The governor "schedutil" may decide which speed to use+ within this range.+ current CPU frequency: Unable to call hardware+ current CPU frequency: 4.02 GHz (asserted by call to kernel)+ boost state support:+ Supported: yes+ Active: yes+ AMD PSTATE Highest Performance: 166. Maximum Frequency: 4.68 GHz.+ AMD PSTATE Nominal Performance: 117. Nominal Frequency: 3.30 GHz.+ AMD PSTATE Lowest Non-linear Performance: 39. Lowest Non-linear Frequency: 1.10 GHz.+ AMD PSTATE Lowest Performance: 15. Lowest Frequency: 400 MHz.+++Diagnostics and Tuning+=======================++Trace Events+--------------++There are two static trace events that can be used for ``amd-pstate``+diagnostics. One of them is the cpu_frequency trace event generally used+by ``CPUFreq``, and the other one is the ``amd_pstate_perf`` trace event+specific to ``amd-pstate``. The following sequence of shell commands can+be used to enable them and see their output (if the kernel is generally+configured to support event tracing). ::++ root@hr-test1:/home/ray# cd /sys/kernel/tracing/+ root@hr-test1:/sys/kernel/tracing# echo 1 > events/amd_cpu/enable+ root@hr-test1:/sys/kernel/tracing# cat trace+ # tracer: nop+ #+ # entries-in-buffer/entries-written: 47827/42233061 #P:2+ #+ # _-----=> irqs-off+ # / _----=> need-resched+ # | / _---=> hardirq/softirq+ # || / _--=> preempt-depth+ # ||| / delay+ # TASK-PID CPU# |||| TIMESTAMP FUNCTION+ # | | | |||| | |+ <idle>-0 [000] d.s. 244057.464842: amd_pstate_perf: amd_min_perf=39 amd_des_perf=39 amd_max_perf=166 cpu_id=0 prev=0x2727a6 value=0x2727a6+ <idle>-0 [000] d.h. 244057.475436: amd_pstate_perf: amd_min_perf=39 amd_des_perf=39 amd_max_perf=166 cpu_id=0 prev=0x2727a6 value=0x2727a6+ <idle>-0 [000] d.h. 244057.476629: amd_pstate_perf: amd_min_perf=39 amd_des_perf=39 amd_max_perf=166 cpu_id=0 prev=0x2727a6 value=0x2727a6+ <idle>-0 [000] d.s. 244057.484847: amd_pstate_perf: amd_min_perf=39 amd_des_perf=39 amd_max_perf=166 cpu_id=0 prev=0x2727a6 value=0x2727a6+ <idle>-0 [000] d.h. 244057.499821: amd_pstate_perf: amd_min_perf=39 amd_des_perf=39 amd_max_perf=166 cpu_id=0 prev=0x2727a6 value=0x2727a6+ avahi-daemon-528 [000] d... 244057.513568: amd_pstate_perf: amd_min_perf=39 amd_des_perf=39 amd_max_perf=166 cpu_id=0 prev=0x2727a6 value=0x2727a6++The cpu_frequency trace event will be triggered either by the ``schedutil`` scaling+governor (for the policies it is attached to), or by the ``CPUFreq`` core (for the+policies with other scaling governors).+++Reference+===========++..[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming,+ https://www.amd.com/system/files/TechDocs/24593.pdf++..[2] Advanced Configuration and Power Interface Specification,+ https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf++..[3] Processor Programming Reference (PPR) for AMD Family 19h Model 21h, Revision B0 Processors+ https://www.amd.com/system/files/TechDocs/55898_B1_pub_0.50.zip+
From: Jinzhou Su <redacted>
Add a new function to enable CPPC feature. This function
will write Continuous Performance Control package
EnableRegister field on the processor.
Signed-off-by: Jinzhou Su <redacted>
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
drivers/acpi/cppc_acpi.c | 48 ++++++++++++++++++++++++++++++++++++++++
include/acpi/cppc_acpi.h | 5 +++++
2 files changed, 53 insertions(+)
@@ -1220,6 +1220,54 @@ int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs)}EXPORT_SYMBOL_GPL(cppc_get_perf_ctrs);+/**+*cppc_set_enable-SettoenableCPPContheprocessorbywritingthe+*ContinuousPerformanceControlpackageEnableRegisterfeild.+*@cpu:CPUforwhichtoenableCPPCregister.+*@enable:0-disable,1-enableCPPCfeatureontheprocessor.+*+*Return:0forsuccess,-ERRNOor-EIOotherwise.+*/+intcppc_set_enable(intcpu,u32enable)
This should take a bool instead of u32 for enable, you can only enable
or diable cppc. The only caller I see is in patch 7/21 in which the
enable arg is already a bool that's converted to a u32. This also allows
for the removal of the enable value check.
You should consider merging this patch with patch 7/21. This patch adds
the cppc_set_enable() routine but has no users. The only caller I find is
in patch 7/21.
-Nathan
quoted hunk
+{
+ int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpu);
+ struct cpc_register_resource *enable_reg;
+ struct cpc_desc *cpc_desc = per_cpu(cpc_desc_ptr, cpu);
+ struct cppc_pcc_data *pcc_ss_data = NULL;
+ int ret = -1;
+
+ /* check the input value*/
+ if (cpu < 0 || cpu > num_possible_cpus() - 1 || enable > 1)
+ return -ENODEV;
+
+ if (!cpc_desc) {
+ pr_debug("No CPC descriptor for CPU:%d\n", cpu);
+ return -ENODEV;
+ }
+
+ enable_reg = &cpc_desc->cpc_regs[ENABLE];
+
+ if (CPC_IN_PCC(enable_reg)) {
+
+ if (pcc_ss_id < 0)
+ return -EIO;
+
+ ret = cpc_write(cpu, enable_reg, enable);
+ if (ret)
+ return ret;
+
+ pcc_ss_data = pcc_data[pcc_ss_id];
+
+ down_write(&pcc_ss_data->pcc_lock);
+ /* after writing CPC, transfer the ownership of PCC to platfrom */
+ ret = send_pcc_cmd(pcc_ss_id, CMD_WRITE);
+ up_write(&pcc_ss_data->pcc_lock);
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(cppc_set_enable);
+
/**
* cppc_set_perf - Set a CPU's performance controls.
* @cpu: CPU for which to set performance controls.
amd-pstate is the AMD CPU performance scaling driver that introduces a
new CPU frequency control mechanism on AMD Zen based CPU series in Linux
kernel. The new mechanism is based on Collaborative processor
performance control (CPPC) which is finer grain frequency management
than legacy ACPI hardware P-States. Current AMD CPU platforms are using
the ACPI P-states driver to manage CPU frequency and clocks with
switching only in 3 P-states. AMD P-States is to replace the ACPI
P-states controls, allows a flexible, low-latency interface for the
Linux kernel to directly communicate the performance hints to hardware.
"amd-pstate" leverages the Linux kernel governors such as *schedutil*,
*ondemand*, etc. to manage the performance hints which are provided by CPPC
hardware functionality. The first version for amd-pstate is to support one
of the Zen3 processors, and we will support more in future after we verify
the hardware and SBIOS functionalities.
There are two types of hardware implementations for amd-pstate: one is full
MSR support and another is shared memory support. It can use
X86_FEATURE_AMD_CPPC_EXT feature flag to distinguish the different types.
Using the new AMD P-States method + kernel governors (*schedutil*,
*ondemand*, ...) to manage the frequency update is the most appropriate
bridge between AMD Zen based hardware processor and Linux kernel, the
processor is able to ajust to the most efficiency frequency according to
the kernel scheduler loading.
Performance Per Watt (PPW) Caculation:
The PPW caculation is referred by below paper:
https://software.intel.com/content/dam/develop/external/us/en/documents/performance-per-what-paper.pdf
Below formula is referred from below spec to measure the PPW:
(F / t) / P = F * t / (t * E) = F / E,
"F" is the number of frames per second.
"P" is power measurd in watts.
"E" is energy measured in joules.
We use the RAPL interface with "perf" tool to get the energy data of the
package power.
The data comparsions between amd-pstate and acpi-freq module are tested on
AMD Cezanne processor:
1) TBench CPU benchmark:
+---------------------------------------------------------------------+
| |
| TBench (Performance Per Watt) |
| Higher is better |
+-------------------+------------------------+------------------------+
| | Performance Per Watt | Performance Per Watt |
| Kernel Module | (Schedutil) | (Ondemand) |
| | Unit: MB / (s * J) | Unit: MB / (s * J) |
+-------------------+------------------------+------------------------+
| | | |
| acpi-cpufreq | 3.022 | 2.969 |
| | | |
+-------------------+------------------------+------------------------+
| | | |
| amd-pstate | 3.131 | 3.284 |
| | | |
+-------------------+------------------------+------------------------+
2) Gitsource CPU benchmark:
+---------------------------------------------------------------------+
| |
| Gitsource (Performance Per Watt) |
| Higher is better |
+-------------------+------------------------+------------------------+
| | Performance Per Watt | Performance Per Watt |
| Kernel Module | (Schedutil) | (Ondemand) |
| | Unit: 1 / (s * J) | Unit: 1 / (s * J) |
+-------------------+------------------------+------------------------+
| | | |
| acpi-cpufreq | 3.42172E-07 | 2.74508E-07 |
| | | |
+-------------------+------------------------+------------------------+
| | | |
| amd-pstate | 4.09141E-07 | 3.47610E-07 |
| | | |
+-------------------+------------------------+------------------------+
3) Speedometer 2.0 CPU benchmark:
+---------------------------------------------------------------------+
| |
| Speedometer 2.0 (Performance Per Watt) |
| Higher is better |
+-------------------+------------------------+------------------------+
| | Performance Per Watt | Performance Per Watt |
| Kernel Module | (Schedutil) | (Ondemand) |
| | Unit: 1 / (s * J) | Unit: 1 / (s * J) |
+-------------------+------------------------+------------------------+
| | | |
| acpi-cpufreq | 0.116111767 | 0.110321664 |
| | | |
+-------------------+------------------------+------------------------+
| | | |
| amd-pstate | 0.115825281 | 0.122024299 |
| | | |
+-------------------+------------------------+------------------------+
According to above average data, we can see this solution has shown better
performance per watt scaling on mobile CPU benchmarks in most of cases.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
drivers/cpufreq/Kconfig.x86 | 13 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/amd-pstate.c | 446 +++++++++++++++++++++++++++++++++++
3 files changed, 460 insertions(+)
create mode 100644 drivers/cpufreq/amd-pstate.c
Go ahead and call out that this is a CPPC driver in the help message, that
is what the driver is.
The reference to "also supports newer AMD CPUs" seems vague, can you elaborate?
quoted hunk
+
+ If in doubt, say N.
+
config X86_ACPI_CPUFREQ
tristate "ACPI Processor P-States driver"
depends on ACPI_PROCESSOR
The lowest_perf value is saved but never referenced, should this be dropped?
It looks like it is used in a later patch to report the lowest_perf value in
sysfs. Do we need to cache it for that? Could just read the value when requested.
You're saving the nominal freq value here but I don't see that it is used
anywhere. It looks like you grab the current nominal freq value via
cppc_get_perf_caps() instead. This could be dropped from the struct.
can you help me understand why you use the cached value for lowest
nonlinear perf here but use the value returned from cppc_get_perf_caps()
in amd_get_lowest_nonlinear_freq()?
Should we be using the value from cppc_get_perf_caps() in both cases?
The amd-pstate hardware support check will be needed by cpupower to know
whether amd-pstate is enabled and supported.
Is this needed?
If acpi_cpc_valid() is false, then the amd_pstate driver would not have been
loaded (see patch 5/21, module init routine will return -ENODEV). If this
driver isn't loaded then this sysfs file won't get created.
Shouldn't the cpupower command just check the scaling_driver in sysfs to see
if it's amd_pstate?
-Nathan
Introduce sysfs attributes to get the different level processor
frequencies.
Can you provide an explanation on why these are needed in addition to the
sysfs files created by the core cpufreq driver? Some of these appear to
be duplicates.
-Nathan
@@ -17,6 +17,10 @@ obj-$(CONFIG_CPU_FREQ_GOV_ATTR_SET) += cpufreq_governor_attr_set.oobj-$(CONFIG_CPUFREQ_DT)+=cpufreq-dt.oobj-$(CONFIG_CPUFREQ_DT_PLATDEV)+=cpufreq-dt-platdev.o+# Traces+CFLAGS_amd-pstate-trace.o:=-I$(src)+amd_pstate-y:=amd-pstate.oamd-pstate-trace.o+################################################################################### x86 drivers.# Link order matters. K8 is preferred to ACPI because of firmware bugs in early
@@ -25,7 +29,7 @@ obj-$(CONFIG_CPUFREQ_DT_PLATDEV) += cpufreq-dt-platdev.o# speedstep-* is preferred over p4-clockmod.obj-$(CONFIG_X86_ACPI_CPUFREQ)+=acpi-cpufreq.o-obj-$(CONFIG_X86_AMD_PSTATE)+=amd-pstate.o+obj-$(CONFIG_X86_AMD_PSTATE)+=amd_pstate.oobj-$(CONFIG_X86_POWERNOW_K8)+=powernow-k8.oobj-$(CONFIG_X86_PCC_CPUFREQ)+=pcc-cpufreq.oobj-$(CONFIG_X86_POWERNOW_K6)+=powernow-k6.o
Hello Ray,
I'd prefer if TRACE_SYSTEM was set to "power". In that way the tracepoint is easier
to find, since it'd be together with other power-related tracepoints. I often do
perf list | grep "power:"
to find all that's available, or equivalently
ls $TRACEFS/events/power/
and if your tracepoint is somewhere else, I wouldn't find it.
Two things here:
1. the field "value" seems redundant, as you're already showing me {min,des,max}_perf.
Maybe you can remove "value" from the output of the trace?
One reason I can think why you're showing me "value", is to let me see if it's the
same as "prev", in which case I'd know the request isn't passed to the hardware.
Is that so? If that's the reason, maybe it would be clear to remove "value", "prev"
and just show a field like "changed={true,false}".
2. the field "type" is a little obscure for someone reading the trace. It can be
0 or 1, and to know what that means one has to read the code. I would suggest
replacing it with a field "fast_switch={true,false}", which is more telling.
What do you think?
Giovanni
[AMD Official Use Only]
Hi all,
Sorry to late response, I am just back from vacation.
-----Original Message-----
From: Fontenot, Nathan <redacted>
Sent: Wednesday, September 29, 2021 1:06 AM
To: Huang, Ray <Ray.Huang@amd.com>; Rafael J . Wysocki
[off-list ref]; Viresh Kumar [off-list ref];
Shuah Khan [off-list ref]; Borislav Petkov [off-list ref];
Peter Zijlstra [off-list ref]; Ingo Molnar [off-list ref];
linux-pm@vger.kernel.org
Cc: Sharma, Deepak <redacted>; Deucher, Alexander
[off-list ref]; Limonciello, Mario
[off-list ref]; Su, Jinzhou (Joe) [off-list ref];
Du, Xiaojian [off-list ref]; linux-kernel@vger.kernel.org;
x86@kernel.org
Subject: Re: [PATCH v2 04/21] ACPI: CPPC: add cppc enable register function
On 9/26/2021 4:05 AM, Huang Rui wrote:
quoted
From: Jinzhou Su <redacted>
Add a new function to enable CPPC feature. This function
will write Continuous Performance Control package
EnableRegister field on the processor.
Signed-off-by: Jinzhou Su <redacted>
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
drivers/acpi/cppc_acpi.c | 48
@@ -1220,6 +1220,54 @@ int cppc_get_perf_ctrs(int cpunum, struct
cppc_perf_fb_ctrs *perf_fb_ctrs)
quoted
}
EXPORT_SYMBOL_GPL(cppc_get_perf_ctrs);
+/**
+ * cppc_set_enable - Set to enable CPPC on the processor by writing the
+ * Continuous Performance Control package EnableRegister feild.
+ * @cpu: CPU for which to enable CPPC register.
+ * @enable: 0 - disable, 1 - enable CPPC feature on the processor.
+ *
+ * Return: 0 for success, -ERRNO or -EIO otherwise.
+ */
+int cppc_set_enable(int cpu, u32 enable)
This should take a bool instead of u32 for enable, you can only enable
or diable cppc. The only caller I see is in patch 7/21 in which the
enable arg is already a bool that's converted to a u32. This also allows
for the removal of the enable value check.
Yes, the bool type should be better than u32 here. Will update it in V3.
You should consider merging this patch with patch 7/21. This patch adds
the cppc_set_enable() routine but has no users. The only caller I find is
in patch 7/21.
I am looking back again, this patch is to provide the new helper in cppc_acpi library under ACPI subsystem.
However, patch 7 is to enable the shared memory APIs in amd-pstate driver.
They are actually the different function implementations. I prefer using the separated patch here.
Thanks,
Ray
From: Giovanni Gherdovich <hidden> Date: 2021-10-13 16:23:18
On Sun, 2021-09-26 at 17:06 +0800, Huang Rui wrote:
Introduce the amd-pstate driver design and implementation.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
Documentation/admin-guide/pm/amd_pstate.rst | 377 ++++++++++++++++++
[... snip ...]
+
+AMD CPPC Performance Capability
+--------------------------------
+
+Highest Performance (RO)
+.........................
+
+It is the absolute maximum performance an individual processor may reach,
+assuming ideal conditions. This performance level may not be sustainable
+for long durations and may only be achievable if other platform components
+are in a specific state; for example, it may require other processors be in
+an idle state. This would be equivalent to the highest frequencies
+supported by the processor.
+
+Nominal (Guaranteed) Performance (RO)
+......................................
+
+It is the maximum sustained performance level of the processor, assuming
+ideal operating conditions. In absence of an external constraint (power,
+thermal, etc.) this is the performance level the processor is expected to
+be able to maintain continuously. All cores/processors are expected to be
+able to sustain their nominal performance state simultaneously.
+
+Lowest non-linear Performance (RO)
+...................................
+
+It is the lowest performance level at which nonlinear power savings are
+achieved, for example, due to the combined effects of voltage and frequency
+scaling. Above this threshold, lower performance levels should be generally
+more energy efficient than higher performance levels. This register
+effectively conveys the most efficient performance level to ``amd-pstate``.
+
+Lowest Performance (RO)
+........................
+
+It is the absolute lowest performance level of the processor. Selecting a
+performance level lower than the lowest nonlinear performance level may
+cause an efficiency penalty but should reduce the instantaneous power
+consumption of the processor.
+
Those above are the CPPC capabilities. All good so far. They're Read Only, and
for each capability you have a file in sysfs. It makes sense to describe them
in this Documentation folder ("admin-guide"). But the following section...
+AMD CPPC Performance Control
+------------------------------
+
+``amd-pstate`` passes performance goals through these registers. The
+register drives the behavior of the desired performance target.
+
+Minimum requested performance (RW)
+...................................
+
+``amd-pstate`` specifies the minimum allowed performance level.
+
+Maximum requested performance (RW)
+...................................
+
+``amd-pstate`` specifies a limit the maximum performance that is expected
+to be supplied by the hardware.
+
+Desired performance target (RW)
+...................................
+
+``amd-pstate`` specifies a desired target in the CPPC performance scale as
+a relative number. This can be expressed as percentage of nominal
+performance (infrastructure max). Below the nominal sustained performance
+level, desired performance expresses the average performance level of the
+processor subject to hardware. Above the nominal performance level,
+processor must provide at least nominal performance requested and go higher
+if current operating conditions allow.
+
+Energy Performance Preference (EPP) (RW)
+.........................................
+
+Provides a hint to the hardware if software wants to bias toward performance
+(0x0) or energy efficiency (0xff).
The section above describes the CPPC "performance controls". They're marked
"Read/Write", but you don't expose them to the user via sysfs, am I right?
Do I understand correctly that with this driver, the AMD System Management
Unit (SMU -- is it the right name?) is *not* working in autonomous mode, but
is almost entirely under the OS control?
By "autonomous mode" I mean: you run a workload, the driver doesn't select any
desired frequency, and the SMU does its thing and selects the CPU clock freq
on its own. That's not what's happing here, AFAIU. I tried using amd-pstate
using the "userspace" governor (very useful for testing ;), and set
frequencies like
echo 1200000 > /sys/devices/system/cpu/cpufreq/policy11/scaling_setspeed
and then, whatever the load on CPU#11, "cpupower monitor" would show me a
constant clock of ~1.2GHz.
Don't get me wrong, this is a very good driver! I'm super happy that the
kernel can finally see all the P-States, instead of just 3.
I'm just trying to clarify that we're using CPPC with autonomous selection
disabled, so I don't think the documentation in admin-guide should describe
features like the R/W "performance controls" that don't make sense in this
context. Especially the "Energy Performance Preference (EPP)", that you would
use to tell the SMU "do what you want, just push a little on the performance
side".
I can see that the driver, internally, is sending "lowest nonlinear" as
minimum perf, 255 as maximum perf, and whatever the governor wants as desired
perf. It just isn't exposed in sysfs so there isn't much point in documenting
that.
[...]
Full MSR Support
-----------------
Some new Zen3 processors such as Cezanne provide the MSR registers directly
while the :c:macro:`X86_FEATURE_AMD_CPPC_EXT` CPU feature flag is set.
``amd-pstate`` can handle the MSR register to implement the fast switch
function in ``CPUFreq`` that can shrink latency of frequency control on the
interrupt context.
A-ha! Cezanne. I have an EPYC Milan, so that's probably why I can't get the
"Full MSR Support". I'll test the "Shared Memory Support" then, and report my
data.
Thanks!
Giovanni
-----Original Message-----
From: Fontenot, Nathan <redacted>
Sent: Wednesday, September 29, 2021 4:41 AM
To: Huang, Ray <Ray.Huang@amd.com>; Rafael J . Wysocki
[off-list ref]; Viresh Kumar [off-list ref];
Shuah Khan [off-list ref]; Borislav Petkov [off-list ref];
Peter Zijlstra [off-list ref]; Ingo Molnar [off-list ref];
linux-pm@vger.kernel.org
Cc: Sharma, Deepak <redacted>; Deucher, Alexander
[off-list ref]; Limonciello, Mario
[off-list ref]; Su, Jinzhou (Joe) [off-list ref];
Du, Xiaojian [off-list ref]; linux-kernel@vger.kernel.org;
x86@kernel.org
Subject: Re: [PATCH v2 05/21] cpufreq: amd: introduce a new amd pstate
driver to support future processors
On 9/26/2021 4:05 AM, Huang Rui wrote:
quoted
amd-pstate is the AMD CPU performance scaling driver that introduces a
new CPU frequency control mechanism on AMD Zen based CPU series in
Linux
quoted
kernel. The new mechanism is based on Collaborative processor
performance control (CPPC) which is finer grain frequency management
than legacy ACPI hardware P-States. Current AMD CPU platforms are using
the ACPI P-states driver to manage CPU frequency and clocks with
switching only in 3 P-states. AMD P-States is to replace the ACPI
P-states controls, allows a flexible, low-latency interface for the
Linux kernel to directly communicate the performance hints to hardware.
"amd-pstate" leverages the Linux kernel governors such as *schedutil*,
*ondemand*, etc. to manage the performance hints which are provided by
CPPC
quoted
hardware functionality. The first version for amd-pstate is to support one
of the Zen3 processors, and we will support more in future after we verify
the hardware and SBIOS functionalities.
There are two types of hardware implementations for amd-pstate: one is
full
quoted
MSR support and another is shared memory support. It can use
X86_FEATURE_AMD_CPPC_EXT feature flag to distinguish the different
types.
quoted
Using the new AMD P-States method + kernel governors (*schedutil*,
*ondemand*, ...) to manage the frequency update is the most appropriate
bridge between AMD Zen based hardware processor and Linux kernel, the
processor is able to ajust to the most efficiency frequency according to
the kernel scheduler loading.
Performance Per Watt (PPW) Caculation:
The PPW caculation is referred by below paper:
Below formula is referred from below spec to measure the PPW:
(F / t) / P = F * t / (t * E) = F / E,
"F" is the number of frames per second.
"P" is power measurd in watts.
"E" is energy measured in joules.
We use the RAPL interface with "perf" tool to get the energy data of the
package power.
The data comparsions between amd-pstate and acpi-freq module are
tested on
quoted
AMD Cezanne processor:
1) TBench CPU benchmark:
+---------------------------------------------------------------------+
| |
| TBench (Performance Per Watt) |
| Higher is better |
+-------------------+------------------------+------------------------+
| | Performance Per Watt | Performance Per Watt |
| Kernel Module | (Schedutil) | (Ondemand) |
| | Unit: MB / (s * J) | Unit: MB / (s * J) |
+-------------------+------------------------+------------------------+
| | | |
| acpi-cpufreq | 3.022 | 2.969 |
| | | |
+-------------------+------------------------+------------------------+
| | | |
| amd-pstate | 3.131 | 3.284 |
| | | |
+-------------------+------------------------+------------------------+
2) Gitsource CPU benchmark:
+---------------------------------------------------------------------+
| |
| Gitsource (Performance Per Watt) |
| Higher is better |
+-------------------+------------------------+------------------------+
| | Performance Per Watt | Performance Per Watt |
| Kernel Module | (Schedutil) | (Ondemand) |
| | Unit: 1 / (s * J) | Unit: 1 / (s * J) |
+-------------------+------------------------+------------------------+
| | | |
| acpi-cpufreq | 3.42172E-07 | 2.74508E-07 |
| | | |
+-------------------+------------------------+------------------------+
| | | |
| amd-pstate | 4.09141E-07 | 3.47610E-07 |
| | | |
+-------------------+------------------------+------------------------+
3) Speedometer 2.0 CPU benchmark:
+---------------------------------------------------------------------+
| |
| Speedometer 2.0 (Performance Per Watt) |
| Higher is better |
+-------------------+------------------------+------------------------+
| | Performance Per Watt | Performance Per Watt |
| Kernel Module | (Schedutil) | (Ondemand) |
| | Unit: 1 / (s * J) | Unit: 1 / (s * J) |
+-------------------+------------------------+------------------------+
| | | |
| acpi-cpufreq | 0.116111767 | 0.110321664 |
| | | |
+-------------------+------------------------+------------------------+
| | | |
| amd-pstate | 0.115825281 | 0.122024299 |
| | | |
+-------------------+------------------------+------------------------+
According to above average data, we can see this solution has shown
better
quoted
performance per watt scaling on mobile CPU benchmarks in most of cases.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
drivers/cpufreq/Kconfig.x86 | 13 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/amd-pstate.c | 446
Go ahead and call out that this is a CPPC driver in the help message, that
is what the driver is.
The reference to "also supports newer AMD CPUs" seems vague, can you
elaborate?
Actually, the detail introduction is in the RST documentation, but I can describe more information here at V3.
quoted
+
+ If in doubt, say N.
+
config X86_ACPI_CPUFREQ
tristate "ACPI Processor P-States driver"
depends on ACPI_PROCESSOR
The lowest_perf value is saved but never referenced, should this be dropped?
It looks like it is used in a later patch to report the lowest_perf value in
sysfs. Do we need to cache it for that? Could just read the value when
requested.
You're saving the nominal freq value here but I don't see that it is used
anywhere. It looks like you grab the current nominal freq value via
cppc_get_perf_caps() instead. This could be dropped from the struct.
quoted
+ u32 lowest_nonlinear_freq;
The same goes for lowest_nonlinear_freq.
The performance and frequency level values won't be changed after the system boots.
We stored them in the data structure, that is to avoid kernel querying or accessing MSR or other ACPI IO operations every time.
quoted
+};
+
+static inline int pstate_enable(bool enable)
+{
+ return wrmsrl_safe(MSR_AMD_CPPC_ENABLE, enable ? 1 : 0);
+}
+
+DEFINE_STATIC_CALL(amd_pstate_enable, pstate_enable);
+
+static inline int amd_pstate_enable(bool enable)
+{
+ return static_call(amd_pstate_enable)(enable);
+}
+
+static int pstate_init_perf(struct amd_cpudata *cpudata)
+{
+ u64 cap1;
+
+ int ret = rdmsrl_safe_on_cpu(cpudata->cpu, MSR_AMD_CPPC_CAP1,
+ &cap1);
+ if (ret)
+ return ret;
+
+ /*
+ * TODO: Introduce AMD specific power feature.
+ *
+ * CPPC entry doesn't indicate the highest performance in some
can you help me understand why you use the cached value for lowest
nonlinear perf here but use the value returned from cppc_get_perf_caps()
in amd_get_lowest_nonlinear_freq()?
Should we be using the value from cppc_get_perf_caps() in both cases?
There are two mainly reasons:
1. In some processors which has "full MSR support", the related performance values are read back from MSR directly.
2. In some processors, the performance value which read back from cppc helper is not expected. For example, please check below bug, the highest perf is obviously not the correct one that will report the processor frequency over 7 GHz.
https://bugzilla.kernel.org/show_bug.cgi?id=211791
-----Original Message-----
From: Fontenot, Nathan <redacted>
Sent: Wednesday, September 29, 2021 5:24 AM
To: Huang, Ray <Ray.Huang@amd.com>; Rafael J . Wysocki
[off-list ref]; Viresh Kumar [off-list ref];
Shuah Khan [off-list ref]; Borislav Petkov [off-list ref];
Peter Zijlstra [off-list ref]; Ingo Molnar [off-list ref];
linux-pm@vger.kernel.org
Cc: Sharma, Deepak <redacted>; Deucher, Alexander
[off-list ref]; Limonciello, Mario
[off-list ref]; Su, Jinzhou (Joe) [off-list ref];
Du, Xiaojian [off-list ref]; linux-kernel@vger.kernel.org;
x86@kernel.org
Subject: Re: [PATCH v2 10/21] cpufreq: amd: add amd-pstate checking
support check attribute
On 9/26/2021 4:05 AM, Huang Rui wrote:
quoted
The amd-pstate hardware support check will be needed by cpupower to
know
quoted
whether amd-pstate is enabled and supported.
Is this needed?
If acpi_cpc_valid() is false, then the amd_pstate driver would not have been
loaded (see patch 5/21, module init routine will return -ENODEV). If this
driver isn't loaded then this sysfs file won't get created.
Shouldn't the cpupower command just check the scaling_driver in sysfs to
see
if it's amd_pstate?
Make sense, thanks! Will update it in V3.
Thanks,
Ray
-----Original Message-----
From: Fontenot, Nathan <redacted>
Sent: Wednesday, September 29, 2021 5:36 AM
To: Huang, Ray <Ray.Huang@amd.com>; Rafael J . Wysocki
[off-list ref]; Viresh Kumar [off-list ref];
Shuah Khan [off-list ref]; Borislav Petkov [off-list ref];
Peter Zijlstra [off-list ref]; Ingo Molnar [off-list ref];
linux-pm@vger.kernel.org
Cc: Sharma, Deepak <redacted>; Deucher, Alexander
[off-list ref]; Limonciello, Mario
[off-list ref]; Su, Jinzhou (Joe) [off-list ref];
Du, Xiaojian [off-list ref]; linux-kernel@vger.kernel.org;
x86@kernel.org
Subject: Re: [PATCH v2 11/21] cpufreq: amd: add amd-pstate frequencies
attributes
On 9/26/2021 4:05 AM, Huang Rui wrote:
quoted
Introduce sysfs attributes to get the different level processor
frequencies.
Can you provide an explanation on why these are needed in addition to the
sysfs files created by the core cpufreq driver? Some of these appear to be
duplicates.
I will clean up the duplicated sysfs with core cpufreq driver in V3.
Thanks,
Ray
-----Original Message-----
From: Giovanni Gherdovich <redacted>
Sent: Thursday, October 14, 2021 12:23 AM
To: Huang, Ray <Ray.Huang@amd.com>; Rafael J . Wysocki
[off-list ref]; Viresh Kumar [off-list ref];
Shuah Khan [off-list ref]; Borislav Petkov [off-list ref];
Peter Zijlstra [off-list ref]; Ingo Molnar [off-list ref];
linux-pm@vger.kernel.org
Cc: Sharma, Deepak <redacted>; Deucher, Alexander
[off-list ref]; Limonciello, Mario
[off-list ref]; Fontenot, Nathan
[off-list ref]; Su, Jinzhou (Joe) [off-list ref];
Du, Xiaojian [off-list ref]; linux-kernel@vger.kernel.org;
x86@kernel.org
Subject: Re: [PATCH v2 21/21] Documentation: amd-pstate: add amd-pstate
driver introduction
On Sun, 2021-09-26 at 17:06 +0800, Huang Rui wrote:
quoted
Introduce the amd-pstate driver design and implementation.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
Documentation/admin-guide/pm/amd_pstate.rst | 377
++++++++++++++++++
quoted
[... snip ...]
quoted
+
+AMD CPPC Performance Capability
+--------------------------------
+
+Highest Performance (RO)
+.........................
+
+It is the absolute maximum performance an individual processor may
+reach, assuming ideal conditions. This performance level may not be
+sustainable for long durations and may only be achievable if other
+platform components are in a specific state; for example, it may
+require other processors be in an idle state. This would be
+equivalent to the highest frequencies supported by the processor.
+
+Nominal (Guaranteed) Performance (RO)
+......................................
+
+It is the maximum sustained performance level of the processor,
+assuming ideal operating conditions. In absence of an external
+constraint (power, thermal, etc.) this is the performance level the
+processor is expected to be able to maintain continuously. All
+cores/processors are expected to be able to sustain their nominal
performance state simultaneously.
quoted
+
+Lowest non-linear Performance (RO)
+...................................
+
+It is the lowest performance level at which nonlinear power savings
+are achieved, for example, due to the combined effects of voltage and
+frequency scaling. Above this threshold, lower performance levels
+should be generally more energy efficient than higher performance
+levels. This register effectively conveys the most efficient performance
level to ``amd-pstate``.
quoted
+
+Lowest Performance (RO)
+........................
+
+It is the absolute lowest performance level of the processor.
+Selecting a performance level lower than the lowest nonlinear
+performance level may cause an efficiency penalty but should reduce
+the instantaneous power consumption of the processor.
+
Those above are the CPPC capabilities. All good so far. They're Read Only,
and for each capability you have a file in sysfs. It makes sense to describe
them in this Documentation folder ("admin-guide"). But the following
section...
quoted
+AMD CPPC Performance Control
+------------------------------
+
+``amd-pstate`` passes performance goals through these registers. The
+register drives the behavior of the desired performance target.
+
+Minimum requested performance (RW)
+...................................
+
+``amd-pstate`` specifies the minimum allowed performance level.
+
+Maximum requested performance (RW)
+...................................
+
+``amd-pstate`` specifies a limit the maximum performance that is
+expected to be supplied by the hardware.
+
+Desired performance target (RW)
+...................................
+
+``amd-pstate`` specifies a desired target in the CPPC performance
+scale as a relative number. This can be expressed as percentage of
+nominal performance (infrastructure max). Below the nominal sustained
+performance level, desired performance expresses the average
+performance level of the processor subject to hardware. Above the
+nominal performance level, processor must provide at least nominal
+performance requested and go higher if current operating conditions
allow.
quoted
+
+Energy Performance Preference (EPP) (RW)
+.........................................
+
+Provides a hint to the hardware if software wants to bias toward
+performance
+(0x0) or energy efficiency (0xff).
The section above describes the CPPC "performance controls". They're
marked "Read/Write", but you don't expose them to the user via sysfs, am I
right?
Yes. Because we use the kernel governors to manage the "performance controls".
Do I understand correctly that with this driver, the AMD System Management
Unit (SMU -- is it the right name?) is *not* working in autonomous mode, but
is almost entirely under the OS control?
By "autonomous mode" I mean: you run a workload, the driver doesn't select
any desired frequency, and the SMU does its thing and selects the CPU clock
freq on its own. That's not what's happing here, AFAIU. I tried using amd-
pstate using the "userspace" governor (very useful for testing ;), and set
frequencies like
echo 1200000 >
/sys/devices/system/cpu/cpufreq/policy11/scaling_setspeed
and then, whatever the load on CPU#11, "cpupower monitor" would show
me a constant clock of ~1.2GHz.
Don't get me wrong, this is a very good driver! I'm super happy that the
kernel can finally see all the P-States, instead of just 3.
I'm just trying to clarify that we're using CPPC with autonomous selection
disabled, so I don't think the documentation in admin-guide should describe
features like the R/W "performance controls" that don't make sense in this
context. Especially the "Energy Performance Preference (EPP)", that you
would use to tell the SMU "do what you want, just push a little on the
performance side".
No problem! 😊 Actually, we combine the kernel governor + AMD SMU Arbiter to manage the target frequency with this driver.
Kernel governor such as "schedutil" can predict the workload to calculate most reasonable desired performance value via Linux CPU CFS scheduler.
Then amd-pstate driver can leverage this governor to manage the "performance controls" to SMU CPU clock DPM Arbiter. Because SMU firmware can detect the MSR operations at the same time as well.
At last, the SMU will calculate the final target frequency in the hardware.
I can see that the driver, internally, is sending "lowest nonlinear" as minimum
perf, 255 as maximum perf, and whatever the governor wants as desired perf.
It just isn't exposed in sysfs so there isn't much point in documenting that.
I will add more descriptions in the RST documentation in V3. Thank you for your suggestion!
quoted
[...]
Full MSR Support
-----------------
Some new Zen3 processors such as Cezanne provide the MSR registers
directly while the :c:macro:`X86_FEATURE_AMD_CPPC_EXT` CPU feature
flag is set.
quoted
``amd-pstate`` can handle the MSR register to implement the fast
switch function in ``CPUFreq`` that can shrink latency of frequency
control on the interrupt context.
A-ha! Cezanne. I have an EPYC Milan, so that's probably why I can't get the
"Full MSR Support". I'll test the "Shared Memory Support" then, and report
my data.
Looking forward to your result data. 😊
Thanks,
Ray
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2021-10-19 16:52:52
On Sun, Sep 26, 2021 at 11:06 AM Huang Rui [off-list ref] wrote:
quoted hunk
From: Mario Limonciello <mario.limonciello@amd.com>
As this is a static check, it should be based upon what is currently
present on the system. This makes probeing more deterministic.
While local APIC flags field (lapic_flags) of cpu core in MADT table is
0, then the cpu core won't be enabled. In this case, _CPC won't be found
in this core, and return back to _CPC invalid with walking through
possible cpus (include disable cpus). This is not expected, so switch to
check online CPUs instead.
Reported-by: Jinzhou Su <redacted>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
drivers/acpi/cppc_acpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2021-10-19 17:00:06
On Sun, Sep 26, 2021 at 11:06 AM Huang Rui [off-list ref] wrote:
From: Jinzhou Su <redacted>
Add a new function to enable CPPC feature. This function
will write Continuous Performance Control package
EnableRegister field on the processor.
And what is going to take place after this write?
Also, it would be good to mention that the user of this function will
be added subsequently.
@@ -1220,6 +1220,54 @@ int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs)}EXPORT_SYMBOL_GPL(cppc_get_perf_ctrs);+/**+*cppc_set_enable-SettoenableCPPContheprocessorbywritingthe+*ContinuousPerformanceControlpackageEnableRegisterfeild.+*@cpu:CPUforwhichtoenableCPPCregister.+*@enable:0-disable,1-enableCPPCfeatureontheprocessor.+*+*Return:0forsuccess,-ERRNOor-EIOotherwise.+*/+intcppc_set_enable(intcpu,u32enable)+{+intpcc_ss_id=per_cpu(cpu_pcc_subspace_idx,cpu);+structcpc_register_resource*enable_reg;+structcpc_desc*cpc_desc=per_cpu(cpc_desc_ptr,cpu);+structcppc_pcc_data*pcc_ss_data=NULL;+intret=-1;++/* check the input value*/+if(cpu<0||cpu>num_possible_cpus()-1||enable>1)
Why not use cpu_possible()? And why enable > 1 is a problem?
+ return -ENODEV;
-EINVAL
+
+ if (!cpc_desc) {
if this is checked, the cpu_possible() check above is redundant.
+ pr_debug("No CPC descriptor for CPU:%d\n", cpu);
+ return -ENODEV;
+ }
+
+ enable_reg = &cpc_desc->cpc_regs[ENABLE];
+
+ if (CPC_IN_PCC(enable_reg)) {
+
+ if (pcc_ss_id < 0)
+ return -EIO;
+
+ ret = cpc_write(cpu, enable_reg, enable);
+ if (ret)
+ return ret;
+
+ pcc_ss_data = pcc_data[pcc_ss_id];
+
+ down_write(&pcc_ss_data->pcc_lock);
+ /* after writing CPC, transfer the ownership of PCC to platfrom */
+ ret = send_pcc_cmd(pcc_ss_id, CMD_WRITE);
+ up_write(&pcc_ss_data->pcc_lock);
+ }
Does it really need to do nothing if the register is not in PCC? If
so, then why?
quoted hunk
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(cppc_set_enable);
+
/**
* cppc_set_perf - Set a CPU's performance controls.
* @cpu: CPU for which to set performance controls.
-----Original Message-----
From: Rafael J. Wysocki <rafael@kernel.org>
Sent: Wednesday, October 20, 2021 1:00 AM
To: Huang, Ray <Ray.Huang@amd.com>
Cc: Rafael J . Wysocki <redacted>; Viresh Kumar
[off-list ref]; Shuah Khan [off-list ref];
Borislav Petkov [off-list ref]; Peter Zijlstra [off-list ref]; Ingo
Molnar [off-list ref]; Linux PM [off-list ref];
Sharma, Deepak [off-list ref]; Deucher, Alexander
[off-list ref]; Limonciello, Mario
[off-list ref]; Fontenot, Nathan
[off-list ref]; Su, Jinzhou (Joe) [off-list ref];
Du, Xiaojian [off-list ref]; Linux Kernel Mailing List <linux-
kernel@vger.kernel.org>; the arch/x86 maintainers [off-list ref]
Subject: Re: [PATCH v2 04/21] ACPI: CPPC: add cppc enable register function
On Sun, Sep 26, 2021 at 11:06 AM Huang Rui [off-list ref] wrote:
quoted
From: Jinzhou Su <redacted>
Add a new function to enable CPPC feature. This function will write
Continuous Performance Control package EnableRegister field on the
processor.
And what is going to take place after this write?
Also, it would be good to mention that the user of this function will be added
subsequently.
After the enable flag is set, the processor hardware can accept the performance goals such as desired perf that programed by kernel and control the processor frequency according to the performance value.
I will mention this in the comment in V3.
@@ -1220,6 +1220,54 @@ int cppc_get_perf_ctrs(int cpunum, struct
cppc_perf_fb_ctrs *perf_fb_ctrs) }
EXPORT_SYMBOL_GPL(cppc_get_perf_ctrs);
+/**
+ * cppc_set_enable - Set to enable CPPC on the processor by writing
+the
+ * Continuous Performance Control package EnableRegister feild.
+ * @cpu: CPU for which to enable CPPC register.
+ * @enable: 0 - disable, 1 - enable CPPC feature on the processor.
+ *
+ * Return: 0 for success, -ERRNO or -EIO otherwise.
+ */
+int cppc_set_enable(int cpu, u32 enable) {
+ int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpu);
+ struct cpc_register_resource *enable_reg;
+ struct cpc_desc *cpc_desc = per_cpu(cpc_desc_ptr, cpu);
+ struct cppc_pcc_data *pcc_ss_data = NULL;
+ int ret = -1;
+
+ /* check the input value*/
+ if (cpu < 0 || cpu > num_possible_cpus() - 1 || enable > 1)
Why not use cpu_possible()? And why enable > 1 is a problem?
Yes, you're right, cpu_possible() is better here.
Will remove "enable > 1", and yes, we should support "disable" as well.
quoted
+ return -ENODEV;
-EINVAL
Updated.
quoted
+
+ if (!cpc_desc) {
if this is checked, the cpu_possible() check above is redundant.
Hmm, if acpi_cppc_processor_probe got failed, some one outside acpi driver would like to call this helper.
Is that possible we get a null cpc descriptor here? Or anything I missed.
quoted
+ pr_debug("No CPC descriptor for CPU:%d\n", cpu);
+ return -ENODEV;
+ }
+
+ enable_reg = &cpc_desc->cpc_regs[ENABLE];
+
+ if (CPC_IN_PCC(enable_reg)) {
+
+ if (pcc_ss_id < 0)
+ return -EIO;
+
+ ret = cpc_write(cpu, enable_reg, enable);
+ if (ret)
+ return ret;
+
+ pcc_ss_data = pcc_data[pcc_ss_id];
+
+ down_write(&pcc_ss_data->pcc_lock);
+ /* after writing CPC, transfer the ownership of PCC to platfrom */
+ ret = send_pcc_cmd(pcc_ss_id, CMD_WRITE);
+ up_write(&pcc_ss_data->pcc_lock);
+ }
Does it really need to do nothing if the register is not in PCC? If so, then why?
Hmm, do you mean we should take care the cases for enabling behavior if register in other spaces such as SYSTEM_MEMORY or FIXED_HARDWARE on different kinds of SBIOS implementation?
Thanks,
Ray
-----Original Message-----
From: Rafael J. Wysocki <rafael@kernel.org>
Sent: Wednesday, October 20, 2021 12:53 AM
To: Huang, Ray <Ray.Huang@amd.com>
Cc: Rafael J . Wysocki <redacted>; Viresh Kumar
[off-list ref]; Shuah Khan [off-list ref];
Borislav Petkov [off-list ref]; Peter Zijlstra [off-list ref]; Ingo
Molnar [off-list ref]; Linux PM [off-list ref];
Sharma, Deepak [off-list ref]; Deucher, Alexander
[off-list ref]; Limonciello, Mario
[off-list ref]; Fontenot, Nathan
[off-list ref]; Su, Jinzhou (Joe) [off-list ref];
Du, Xiaojian [off-list ref]; Linux Kernel Mailing List <linux-
kernel@vger.kernel.org>; the arch/x86 maintainers [off-list ref]
Subject: Re: [PATCH v2 03/21] ACPI: CPPC: Check online CPUs for
determining _CPC is valid
On Sun, Sep 26, 2021 at 11:06 AM Huang Rui [off-list ref] wrote:
quoted
From: Mario Limonciello <mario.limonciello@amd.com>
As this is a static check, it should be based upon what is currently
present on the system. This makes probeing more deterministic.
While local APIC flags field (lapic_flags) of cpu core in MADT table
is 0, then the cpu core won't be enabled. In this case, _CPC won't be
found in this core, and return back to _CPC invalid with walking
through possible cpus (include disable cpus). This is not expected, so
switch to check online CPUs instead.
Reported-by: Jinzhou Su <redacted>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
drivers/acpi/cppc_acpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2021-10-20 13:32:39
On Wed, Oct 20, 2021 at 1:13 PM Huang, Ray [off-list ref] wrote:
[AMD Official Use Only]
quoted
-----Original Message-----
From: Rafael J. Wysocki <rafael@kernel.org>
Sent: Wednesday, October 20, 2021 1:00 AM
To: Huang, Ray <Ray.Huang@amd.com>
Cc: Rafael J . Wysocki <redacted>; Viresh Kumar
[off-list ref]; Shuah Khan [off-list ref];
Borislav Petkov [off-list ref]; Peter Zijlstra [off-list ref]; Ingo
Molnar [off-list ref]; Linux PM [off-list ref];
Sharma, Deepak [off-list ref]; Deucher, Alexander
[off-list ref]; Limonciello, Mario
[off-list ref]; Fontenot, Nathan
[off-list ref]; Su, Jinzhou (Joe) [off-list ref];
Du, Xiaojian [off-list ref]; Linux Kernel Mailing List <linux-
kernel@vger.kernel.org>; the arch/x86 maintainers [off-list ref]
Subject: Re: [PATCH v2 04/21] ACPI: CPPC: add cppc enable register function
On Sun, Sep 26, 2021 at 11:06 AM Huang Rui [off-list ref] wrote:
quoted
From: Jinzhou Su <redacted>
Add a new function to enable CPPC feature. This function will write
Continuous Performance Control package EnableRegister field on the
processor.
And what is going to take place after this write?
Also, it would be good to mention that the user of this function will be added
subsequently.
After the enable flag is set, the processor hardware can accept the performance goals such as desired perf that programed by kernel and control the processor frequency according to the performance value.
Is this the CPPC EnableRegister register described in Section 8.4.7.1
of ACPI 6.4? If so, it would be good to provide this information in
the changelog either.
@@ -1220,6 +1220,54 @@ int cppc_get_perf_ctrs(int cpunum, struct
cppc_perf_fb_ctrs *perf_fb_ctrs) }
EXPORT_SYMBOL_GPL(cppc_get_perf_ctrs);
+/**
+ * cppc_set_enable - Set to enable CPPC on the processor by writing
+the
+ * Continuous Performance Control package EnableRegister feild.
+ * @cpu: CPU for which to enable CPPC register.
+ * @enable: 0 - disable, 1 - enable CPPC feature on the processor.
+ *
+ * Return: 0 for success, -ERRNO or -EIO otherwise.
+ */
+int cppc_set_enable(int cpu, u32 enable) {
+ int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpu);
+ struct cpc_register_resource *enable_reg;
+ struct cpc_desc *cpc_desc = per_cpu(cpc_desc_ptr, cpu);
+ struct cppc_pcc_data *pcc_ss_data = NULL;
+ int ret = -1;
+
+ /* check the input value*/
+ if (cpu < 0 || cpu > num_possible_cpus() - 1 || enable > 1)
Why not use cpu_possible()? And why enable > 1 is a problem?
Yes, you're right, cpu_possible() is better here.
Will remove "enable > 1", and yes, we should support "disable" as well.
quoted
quoted
+ return -ENODEV;
-EINVAL
Updated.
quoted
quoted
+
+ if (!cpc_desc) {
if this is checked, the cpu_possible() check above is redundant.
Hmm, if acpi_cppc_processor_probe got failed, some one outside acpi driver would like to call this helper.
Is that possible we get a null cpc descriptor here? Or anything I missed.
if cpu_possible(cpu) is false, then cpc_desc for cpu will be NULL. If
you check the latter, there's no need to check the former. Of course,
cpc_desc may be NULL for other reasons, but you're checking it anyway.
quoted
quoted
+ pr_debug("No CPC descriptor for CPU:%d\n", cpu);
+ return -ENODEV;
+ }
+
+ enable_reg = &cpc_desc->cpc_regs[ENABLE];
+
+ if (CPC_IN_PCC(enable_reg)) {
+
+ if (pcc_ss_id < 0)
+ return -EIO;
+
+ ret = cpc_write(cpu, enable_reg, enable);
+ if (ret)
+ return ret;
+
+ pcc_ss_data = pcc_data[pcc_ss_id];
+
+ down_write(&pcc_ss_data->pcc_lock);
+ /* after writing CPC, transfer the ownership of PCC to platfrom */
+ ret = send_pcc_cmd(pcc_ss_id, CMD_WRITE);
+ up_write(&pcc_ss_data->pcc_lock);
+ }
Does it really need to do nothing if the register is not in PCC? If so, then why?
Hmm, do you mean we should take care the cases for enabling behavior if register in other spaces such as SYSTEM_MEMORY or FIXED_HARDWARE on different kinds of SBIOS implementation?
This is a generic interface and it should cover all of the valid use
cases, so yes.
-----Original Message-----
From: Rafael J. Wysocki <rafael@kernel.org>
Sent: Wednesday, October 20, 2021 9:32 PM
To: Huang, Ray <Ray.Huang@amd.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>; Rafael J . Wysocki
[off-list ref]; Viresh Kumar [off-list ref];
Shuah Khan [off-list ref]; Borislav Petkov [off-list ref];
Peter Zijlstra [off-list ref]; Ingo Molnar [off-list ref];
Linux PM [off-list ref]; Sharma, Deepak
[off-list ref]; Deucher, Alexander
[off-list ref]; Limonciello, Mario
[off-list ref]; Fontenot, Nathan
[off-list ref]; Su, Jinzhou (Joe) [off-list ref];
Du, Xiaojian [off-list ref]; Linux Kernel Mailing List <linux-
kernel@vger.kernel.org>; the arch/x86 maintainers [off-list ref]
Subject: Re: [PATCH v2 04/21] ACPI: CPPC: add cppc enable register function
On Wed, Oct 20, 2021 at 1:13 PM Huang, Ray [off-list ref]
wrote:
quoted
[AMD Official Use Only]
quoted
-----Original Message-----
From: Rafael J. Wysocki <rafael@kernel.org>
Sent: Wednesday, October 20, 2021 1:00 AM
To: Huang, Ray <Ray.Huang@amd.com>
Cc: Rafael J . Wysocki <redacted>; Viresh Kumar
[off-list ref]; Shuah Khan [off-list ref];
Borislav Petkov [off-list ref]; Peter Zijlstra [off-list ref];
Ingo Molnar [off-list ref]; Linux PM [off-list ref];
Sharma, Deepak [off-list ref]; Deucher, Alexander
[off-list ref]; Limonciello, Mario
[off-list ref]; Fontenot, Nathan
[off-list ref]; Su, Jinzhou (Joe)
[off-list ref];
quoted
quoted
Du, Xiaojian [off-list ref]; Linux Kernel Mailing List
<linux- kernel@vger.kernel.org>; the arch/x86 maintainers
[off-list ref]
Subject: Re: [PATCH v2 04/21] ACPI: CPPC: add cppc enable register
function
On Sun, Sep 26, 2021 at 11:06 AM Huang Rui [off-list ref]
wrote:
quoted
quoted
quoted
From: Jinzhou Su <redacted>
Add a new function to enable CPPC feature. This function will
write Continuous Performance Control package EnableRegister field
on the processor.
And what is going to take place after this write?
Also, it would be good to mention that the user of this function
will be added subsequently.
After the enable flag is set, the processor hardware can accept the
performance goals such as desired perf that programed by kernel and control
the processor frequency according to the performance value.
Is this the CPPC EnableRegister register described in Section 8.4.7.1 of ACPI
6.4? If so, it would be good to provide this information in the changelog
either.
I see, yes. We should follow the spec definition for general CPPC function helper.
@@ -1220,6 +1220,54 @@ int cppc_get_perf_ctrs(int cpunum, struct
cppc_perf_fb_ctrs *perf_fb_ctrs) }
EXPORT_SYMBOL_GPL(cppc_get_perf_ctrs);
+/**
+ * cppc_set_enable - Set to enable CPPC on the processor by
+writing the
+ * Continuous Performance Control package EnableRegister feild.
+ * @cpu: CPU for which to enable CPPC register.
+ * @enable: 0 - disable, 1 - enable CPPC feature on the processor.
+ *
+ * Return: 0 for success, -ERRNO or -EIO otherwise.
+ */
+int cppc_set_enable(int cpu, u32 enable) {
+ int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpu);
+ struct cpc_register_resource *enable_reg;
+ struct cpc_desc *cpc_desc = per_cpu(cpc_desc_ptr, cpu);
+ struct cppc_pcc_data *pcc_ss_data = NULL;
+ int ret = -1;
+
+ /* check the input value*/
+ if (cpu < 0 || cpu > num_possible_cpus() - 1 || enable >
+ 1)
Why not use cpu_possible()? And why enable > 1 is a problem?
Yes, you're right, cpu_possible() is better here.
Will remove "enable > 1", and yes, we should support "disable" as well.
quoted
quoted
+ return -ENODEV;
-EINVAL
Updated.
quoted
quoted
+
+ if (!cpc_desc) {
if this is checked, the cpu_possible() check above is redundant.
Hmm, if acpi_cppc_processor_probe got failed, some one outside acpi
driver would like to call this helper.
quoted
Is that possible we get a null cpc descriptor here? Or anything I missed.
if cpu_possible(cpu) is false, then cpc_desc for cpu will be NULL. If you check
the latter, there's no need to check the former. Of course, cpc_desc may be
NULL for other reasons, but you're checking it anyway.
Yes. If the cpc_desc is initialized, the cpu has to be in possible mask. I will clean it up in V3.
quoted
quoted
quoted
+ pr_debug("No CPC descriptor for CPU:%d\n", cpu);
+ return -ENODEV;
+ }
+
+ enable_reg = &cpc_desc->cpc_regs[ENABLE];
+
+ if (CPC_IN_PCC(enable_reg)) {
+
+ if (pcc_ss_id < 0)
+ return -EIO;
+
+ ret = cpc_write(cpu, enable_reg, enable);
+ if (ret)
+ return ret;
+
+ pcc_ss_data = pcc_data[pcc_ss_id];
+
+ down_write(&pcc_ss_data->pcc_lock);
+ /* after writing CPC, transfer the ownership of PCC to
platfrom */
quoted
quoted
quoted
+ ret = send_pcc_cmd(pcc_ss_id, CMD_WRITE);
+ up_write(&pcc_ss_data->pcc_lock);
+ }
Does it really need to do nothing if the register is not in PCC? If so, then
why?
quoted
quoted
Hmm, do you mean we should take care the cases for enabling behavior if
register in other spaces such as SYSTEM_MEMORY or FIXED_HARDWARE on
different kinds of SBIOS implementation?
This is a generic interface and it should cover all of the valid use cases, so yes.
-----Original Message-----
From: Giovanni Gherdovich <redacted>
Sent: Wednesday, October 6, 2021 4:13 PM
To: Huang, Ray <Ray.Huang@amd.com>; Rafael J . Wysocki
[off-list ref]; Viresh Kumar [off-list ref];
Shuah Khan [off-list ref]; Borislav Petkov [off-list ref];
Peter Zijlstra [off-list ref]; Ingo Molnar [off-list ref];
linux-pm@vger.kernel.org
Cc: Sharma, Deepak <redacted>; Deucher, Alexander
[off-list ref]; Limonciello, Mario
[off-list ref]; Fontenot, Nathan
[off-list ref]; Su, Jinzhou (Joe) [off-list ref];
Du, Xiaojian [off-list ref]; linux-kernel@vger.kernel.org;
x86@kernel.org
Subject: Re: [PATCH v2 08/21] cpufreq: amd: add trace for amd-pstate
module
On Sun, 2021-09-26 at 17:05 +0800, Huang Rui wrote:
quoted
Add trace event to monitor the performance value changes which is
controlled by cpu governors.
Signed-off-by: Huang Rui <ray.huang@amd.com>
---
drivers/cpufreq/Makefile | 6 +-
drivers/cpufreq/amd-pstate-trace.c | 2 +
drivers/cpufreq/amd-pstate-trace.h | 96
Hello Ray,
I'd prefer if TRACE_SYSTEM was set to "power". In that way the tracepoint is
easier to find, since it'd be together with other power-related tracepoints. I
often do
perf list | grep "power:"
to find all that's available, or equivalently
ls $TRACEFS/events/power/
and if your tracepoint is somewhere else, I wouldn't find it.
(I just found this mail in my "Junk Email" folder... sorry to miss the mail)
The reason that I create an other file to store the tracer is that I would like to make amd-pstate as a module.
So far, the module is better for debugging at early phase. If we adds it into power system, the amd-pstate has to build in kernel.
value &= ~REQ_MAX_PERF(~0L);
value |= REQ_MAX_PERF(max_perf);
+ trace_amd_pstate_perf(min_perf, des_perf, max_perf,
+ cpudata->cpu, prev, value, type);
Two things here:
1. the field "value" seems redundant, as you're already showing me
{min,des,max}_perf.
Maybe you can remove "value" from the output of the trace?
One reason I can think why you're showing me "value", is to let me see if
it's the
same as "prev", in which case I'd know the request isn't passed to the
hardware.
Is that so? If that's the reason, maybe it would be clear to remove "value",
"prev"
and just show a field like "changed={true,false}".
Yes, I would like monitor the status and changes that {min,des,max}_perf.
Agree, I will refine and clean up the prints in V3.
2. the field "type" is a little obscure for someone reading the trace. It can be
0 or 1, and to know what that means one has to read the code. I would
suggest
replacing it with a field "fast_switch={true,false}", which is more telling.
What do you think?