For both the d and e options in 'cpupower idle_set' command, an
atoi() conversion is done without checking if the input argument
is all numeric. So, an atoi conversion is done on any character
provided as input and the CPU idle_set operation continues with
that integer value, which may not be what is intended or entirely
correct.
The output of cpuidle-set before patch is as follows:
[root@xxx cpupower]# cpupower idle-set -e 1$
Idlestate 1 enabled on CPU 0
[snip]
Idlestate 1 enabled on CPU 47
[root@xxx cpupower]# cpupower idle-set -e 11
Idlestate 11 not available on CPU 0
[snip]
Idlestate 11 not available on CPU 47
[root@xxx cpupower]# cpupower idle-set -d 12
Idlestate 12 not available on CPU 0
[snip]
Idlestate 12 not available on CPU 47
[root@xxx cpupower]# cpupower idle-set -d qw
Idlestate 0 disabled on CPU 0
[snip]
Idlestate 0 disabled on CPU 47
This patch adds a check for both d and e options in cpuidle-set.c
to see that the idle_set value is all numeric before doing a
string-to-int conversion using strtol().
The output of cpuidle-set after the patch is as below:
[root@xxx cpupower]# ./cpupower idle-set -e 1$
Bad idle_set value: 1$. Integer expected
[root@xxx cpupower]# ./cpupower idle-set -e 11
Idlestate 11 not available on CPU 0
[snip]
Idlestate 11 not available on CPU 47
[root@xxx cpupower]# ./cpupower idle-set -d 12
Idlestate 12 not available on CPU 0
[snip]
Idlestate 12 not available on CPU 47
[root@xxx cpupower]# ./cpupower idle-set -d qw
Bad idle_set value: qw. Integer expected
Signed-off-by: Brahadambal Srinivasan <latha@linux.vnet.ibm.com>
Signed-off-by: Likhitha Korrapati <likhitha@linux.ibm.com>
Tested-by: Pavithra Prakash <pavrampu@linux.vnet.ibm.com>
Reviewed-by: Rick Lindsley <ricklind@linux.vnet.ibm.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
If boost sysfs (/sys/devices/system/cpu/cpufreq/boost) file is present
turbo-boost is feature is supported in the hardware. By default this
feature should be enabled. But to disable/enable it write to the sysfs
file. Use the same to control this feature via cpupower.
To enable:
cpupower set --turbo-boost 1
To disable:
cpupower set --turbo-boost 0
Acked-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Wyes Karny <wyes.karny@amd.com>
Tested-by: Perry Yuan <Perry.Yuan@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
amd_pstate supports changing of its mode dynamically via `status` sysfs
file. Add the same capability in cpupower. To change the mode to active
mode use below command:
cpupower set --amd-pstate-mode active
Acked-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Wyes Karny <wyes.karny@amd.com>
Tested-by: Perry Yuan <Perry.Yuan@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
amd_pstate and intel_pstate active mode drivers support energy
performance preference feature. Through this user can convey it's
energy/performance preference to platform. Add this value change
capability to cpupower.
To change the EPP value use below command:
cpupower set --epp performance
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Wyes Karny <wyes.karny@amd.com>
Tested-by: Perry Yuan <Perry.Yuan@amd.com>
Acked-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
This CPU power monitor shows the power consumption
as exposed by the powercap subsystem, cmp with:
Documentation/power/powercap/powercap.rst
cpupower monitor -m RAPL
| RAPL
CPU| pack | core | unco
0|6853926|967832|442381
8|6853926|967832|442381
1|6853926|967832|442381
9|6853926|967832|442381
Unfortunately RAPL domains cannot be directly mapped to the corresponding
CPU socket/package, core it belongs to.
Not sure this is possible at all with the current data exposed from the
kernel.
Still it can be worthful information for developers trying to optimize
power consumption of workloads or their system in general.
Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: Zhang Rui <rui.zhang@intel.com>
CC: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Read out powercap zone information via:
cpupower powercap-info
and show the zone hierarchy to the user:
./cpupower powercap-info
Driver: intel-rapl
Powercap domain hierarchy:
Zone: package-0 (enabled)
Power consumption can be monitored in micro Watts
Zone: core (disabled)
Power consumption can be monitored in micro Watts
Zone: uncore (disabled)
Power consumption can be monitored in micro Watts
Zone: dram (disabled)
Power consumption can be monitored in micro Watts
There is a dummy -a option for powercap-info which can/should be used to
show more detailed info later. Like that other args can be added easily
later as well.
A enable/disable option via powercap-set subcommand is also an enhancement
for later.
Also not all RAPL domains are shown. The func walking through RAPL
subdomains is restricted and hardcoded to: "intel-rapl/intel-rapl:0"
On my system above powercap domains map to:
intel-rapl/intel-rapl:0
-> pack (age-0)
intel-rapl/intel-rapl:0/intel-rapl:0:0
-> core
intel-rapl/intel-rapl:0/intel-rapl:0:1
-> uncore
Missing ones on my system are:
intel-rapl-mmio/intel-rapl-mmio:0
-> pack (age-0)
intel-rapl/intel-rapl:1
-> psys
This could get enhanced in:
struct powercap_zone *powercap_init_zones()
and adopted to walk through all intel-rapl zones, but
also to other powercap drivers like dtpm
(Dynamic Thermal Power Management framework),
cmp with: drivers/powercap/dtpm_*
Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The default output of cpupower info utils shows unexpected output
when CPU 0 is disabled.
Considering a case where CPU 0 is disabled, output of cpupower idle-info:
Before change:
cpupower idle-info
CPUidle driver: pseries_idle
CPUidle governor: menu
analyzing CPU 0:
*is offline
After change:
./cpupower idle-info
CPUidle driver: pseries_idle
CPUidle governor: menu
analyzing CPU 50:
Number of idle states: 2
Available idle states: snooze CEDE
snooze:
Flags/Description: snooze
Latency: 0
Usage: 101748
Duration: 2724058
CEDE:
Flags/Description: CEDE
Latency: 12
Usage: 270004
Duration: 283019526849
If -c option is not passed, CPU 0 was chosen as the default chosen CPU to
display details. However when CPU 0 is offline, it results in showing
unexpected output. This commit chooses the base_cpu
instead of CPU 0, hence keeping the output more relevant in all cases.
The base_cpu is the number of CPU on which the calling thread is
currently executing.
Signed-off-by: Saket Kumar Bhaskar <skb99@linux.vnet.ibm.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
AMD P-State kernel module is using the fine grain frequency instead of
acpi hardware pstate. So add a function to print performance and
frequency values.
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
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.
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
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-State 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
similar 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-State function.
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Introduce the marco definitions and access helper function for
AMD P-State 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 P-State cpufreq driver for cpupower utilities.
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
If kernel starts the AMD P-State module, the cpupower will initial the
capability flag as CPUPOWER_CAP_AMD_PSTATE. And once AMD P-State
capability is set, it won't need to set legacy ACPI relative
capabilities anymore.
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The processor with AMD P-State function also supports legacy ACPI
hardware P-States feature as well. Once driver sets AMD P-State eanbled,
the processor will respond the finer grain AMD P-State feature instead of
legacy ACPI P-States. So it introduces the cpupower_amd_pstate_enabled()
to check whether the current kernel enables AMD P-State or AMD CPUFreq
module.
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Remove the family check for accessing the MSR_AMD_HWCR MSR and replace
it with a cpupower cap flag.
This update also allows for the removal of the local cpupower_cpu_info
variable in cpufreq_has_boost_support() since we no longer need it to
check the family.
Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com>
Reviewed-by: Robert Richter <rrichter@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The decode_pstates() routine no longer uses the CPU family and
the caleed routines (get_cof() and get_did()) can grab the family
from the global cpupower_cpu_info struct. These update removes
passing the family arg to all these routines.
Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com>
Reviewed-by: Robert Richter <rrichter@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The enabled bit (bit 63) is common for all families so we can remove
the multiple enabled checks based on family and have a common check
for HW pstate enabled.
Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com>
Reviewed-by: Robert Richter <rrichter@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The family checks in get_cof() and get_did() need to use the
correct MSR format depending on the family. Add a cpupower
capability for using the pstatedef (family 17h and newer) to
control this instead of direct family checks.
Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com>
Reviewed-by: Robert Richter <rrichter@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The pscur variable is set but not uused, just remove it.
This may have previsously been set to validate the MSR_AMD_PSTATE_STATUS
MSR. With the addition of the CPUPOWER_CAP_AMD_HW_PSTATE cap flag this
is no longer needed since the cpuid bit to enable this cap flag also
validates that the MSR_AMD_PSTATE_STATUS MSR is present.
Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com>
Reviewed-by: Robert Richter <rrichter@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Add a check in get_cpu_info() for the ability to read frequencies
from hardware and set the CPUPOWER_CAP_AMD_HW_PSTATE cpuid flag.
The cpuid flag is set when CPUID_80000007_EDX[7] is set,
which is all families >= 10h. The check excludes family 14h
because HW pstate reporting was not implemented on family 14h.
This is intended to reduce family checks in the main code paths.
Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com>
Reviewed-by: Robert Richter <rrichter@amd.com>
Reviewed-by: skhan@linuxfoundation.org
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The name is Core Performance Boost (CPB) for the cpuid flag. Correct
cpuid caps flag to use this name (instead of CBP).
Signed-off-by: Robert Richter <rrichter@amd.com>
Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The msr_pstate union struct named fam17h_bits is misleading since
this is the struct to use for all families >= 0x17, not just
for family 0x17. Rename the bits structs to be 'pstate' (for pre
family 17h CPUs) and 'pstatedef' (for CPUs since fam 17h) to align
closer with PPR/BDKG (1) naming.
There are no functional changes as part of this update.
1: AMD Processor Programming Reference (PPR) and BIOS and
Kernel Developer's Guide (BKDG) available at:
http://developer.amd.com/resources/developer-guides-manuals
Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com>
Reviewed-by: Robert Richter <rrichter@amd.com>
Reviewed-by: skhan@linuxfoundation.org
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Pull power management updates from Rafael Wysocki:
"These update cpufreq (core and drivers), cpuidle (polling state
implementation and the PSCI driver), the OPP (operating performance
points) framework, devfreq (core and drivers), the power capping RAPL
(Running Average Power Limit) driver, the Energy Model support, the
generic power domains (genpd) framework, the ACPI device power
management, the core system-wide suspend code and power management
utilities.
Specifics:
- Use local_clock() instead of jiffies in the cpufreq statistics to
improve accuracy (Viresh Kumar).
- Fix up OPP usage in the cpufreq-dt and qcom-cpufreq-nvmem cpufreq
drivers (Viresh Kumar).
- Clean up the cpufreq core, the intel_pstate driver and the
schedutil cpufreq governor (Rafael Wysocki).
- Fix up error code paths in the sti-cpufreq and mediatek cpufreq
drivers (Yangtao Li, Qinglang Miao).
- Fix cpufreq_online() to return error codes instead of success (0)
in all cases when it fails (Wang ShaoBo).
- Add mt8167 support to the mediatek cpufreq driver and blacklist
mt8516 in the cpufreq-dt-platdev driver (Fabien Parent).
- Modify the tegra194 cpufreq driver to always return values from the
frequency table as the current frequency and clean up that driver
(Sumit Gupta, Jon Hunter).
- Modify the arm_scmi cpufreq driver to allow it to discover the
power scale present in the performance protocol and provide this
information to the Energy Model (Lukasz Luba).
- Add missing MODULE_DEVICE_TABLE to several cpufreq drivers (Pali
Rohár).
- Clean up the CPPC cpufreq driver (Ionela Voinescu).
- Fix NVMEM_IMX_OCOTP dependency in the imx cpufreq driver (Arnd
Bergmann).
- Rework the poling interval selection for the polling state in
cpuidle (Mel Gorman).
- Enable suspend-to-idle for PSCI OSI mode in the PSCI cpuidle driver
(Ulf Hansson).
- Modify the OPP framework to support empty (node-less) OPP tables in
DT for passing dependency information (Nicola Mazzucato).
- Fix potential lockdep issue in the OPP core and clean up the OPP
core (Viresh Kumar).
- Modify dev_pm_opp_put_regulators() to accept a NULL argument and
update its users accordingly (Viresh Kumar).
- Add frequency changes tracepoint to devfreq (Matthias Kaehlcke).
- Add support for governor feature flags to devfreq, make devfreq
sysfs file permissions depend on the governor and clean up the
devfreq core (Chanwoo Choi).
- Clean up the tegra20 devfreq driver and deprecate it to allow
another driver based on EMC_STAT to be used instead of it (Dmitry
Osipenko).
- Add interconnect support to the tegra30 devfreq driver, allow it to
take the interconnect and OPP information from DT and clean it up
(Dmitry Osipenko).
- Add interconnect support to the exynos-bus devfreq driver along
with interconnect properties documentation (Sylwester Nawrocki).
- Add suport for AMD Fam17h and Fam19h processors to the RAPL power
capping driver (Victor Ding, Kim Phillips).
- Fix handling of overly long constraint names in the powercap
framework (Lukasz Luba).
- Fix the wakeup configuration handling for bridges in the ACPI
device power management core (Rafael Wysocki).
- Add support for using an abstract scale for power units in the
Energy Model (EM) and document it (Lukasz Luba).
- Add em_cpu_energy() micro-optimization to the EM (Pavankumar
Kondeti).
- Modify the generic power domains (genpd) framwework to support
suspend-to-idle (Ulf Hansson).
- Fix creation of debugfs nodes in genpd (Thierry Strudel).
- Clean up genpd (Lina Iyer).
- Clean up the core system-wide suspend code and make it print driver
flags for devices with debug enabled (Alex Shi, Patrice Chotard,
Chen Yu).
- Modify the ACPI system reboot code to make it prepare for system
power off to avoid confusing the platform firmware (Kai-Heng Feng).
- Update the pm-graph (multiple changes, mostly usability-related)
and cpupower (online and offline CPU information support) PM
utilities (Todd Brandt, Brahadambal Srinivasan)"
* tag 'pm-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (86 commits)
cpufreq: Fix cpufreq_online() return value on errors
cpufreq: Fix up several kerneldoc comments
cpufreq: stats: Use local_clock() instead of jiffies
cpufreq: schedutil: Simplify sugov_update_next_freq()
cpufreq: intel_pstate: Simplify intel_cpufreq_update_pstate()
PM: domains: create debugfs nodes when adding power domains
opp: of: Allow empty opp-table with opp-shared
dt-bindings: opp: Allow empty OPP tables
media: venus: dev_pm_opp_put_*() accepts NULL argument
drm/panfrost: dev_pm_opp_put_*() accepts NULL argument
drm/lima: dev_pm_opp_put_*() accepts NULL argument
PM / devfreq: exynos: dev_pm_opp_put_*() accepts NULL argument
cpufreq: qcom-cpufreq-nvmem: dev_pm_opp_put_*() accepts NULL argument
cpufreq: dt: dev_pm_opp_put_regulators() accepts NULL argument
opp: Allow dev_pm_opp_put_*() APIs to accept NULL opp_table
opp: Don't create an OPP table from dev_pm_opp_get_opp_table()
cpufreq: dt: Don't (ab)use dev_pm_opp_get_opp_table() to create OPP table
opp: Reduce the size of critical section in _opp_kref_release()
PM / EM: Micro optimization in em_cpu_energy
cpufreq: arm_scmi: Discover the power scale in performance protocol
...
When a user tries to modify cpuidle or cpufreq properties on offline
CPUs, the tool returns success (exit status 0) but also does not provide
any warning message regarding offline cpus that may have been specified
but left unchanged. In case of all or a few CPUs being offline, it can be
difficult to keep track of which CPUs didn't get the new frequency or idle
state set. Silent failures are difficult to keep track of when there are a
huge number of CPUs on which the action is performed.
This patch adds helper functions to find both online and offline CPUs and
print them out accordingly.
We use these helper functions in cpuidle-set and cpufreq-set to print an
additional message if the user attempts to modify offline cpus.
Reported-by: Pavithra R. Prakash <pavrampu@in.ibm.com>
Signed-off-by: Brahadambal Srinivasan <latha@linux.vnet.ibm.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Building cpupower with -fno-common in CFLAGS results in errors due to
multiple definitions of the 'cpu_count' and 'start_time' variables.
./utils/idle_monitor/snb_idle.o:./utils/idle_monitor/cpupower-monitor.h:28:
multiple definition of `cpu_count';
./utils/idle_monitor/nhm_idle.o:./utils/idle_monitor/cpupower-monitor.h:28:
first defined here
...
./utils/idle_monitor/cpuidle_sysfs.o:./utils/idle_monitor/cpuidle_sysfs.c:22:
multiple definition of `start_time';
./utils/idle_monitor/amd_fam14h_idle.o:./utils/idle_monitor/amd_fam14h_idle.c:85:
first defined here
The -fno-common option will be enabled by default in GCC 10.
Bug: https://bugs.gentoo.org/707462
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Commit ae2917093f ("tools/power/cpupower: Display boost frequency
separately") modified the library function:
struct cpufreq_available_frequencies
*cpufreq_get_available_frequencies(unsigned int cpu)
to
struct cpufreq_frequencies
*cpufreq_get_frequencies(const char *type, unsigned int cpu)
This patch recovers the old API and implements the new functionality
in a newly introduce method:
struct cpufreq_boost_frequencies
*cpufreq_get_available_frequencies(unsigned int cpu)
This one should get merged into stable kernels back to 5.0 when
the above had been introduced.
Fixes: ae2917093f ("tools/power/cpupower: Display boost frequency separately")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
AMD Zen 2 introduces the RDPRU instruction which can be used to access some
processor registers which are typically only accessible in privilege level
0. ECX specifies the register to read and EDX:EAX will contain the value read.
ECX: 0 - Register MPERF
1 - Register APERF
This has the added advantage of not having to use the msr module, since the
userspace to kernel transitions which occur during each read_msr() might
cause APERF and MPERF to go out of sync.
Signed-off-by: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The per_cpu_schedule flag is used to move the cpupower process to the cpu
on which we are looking to read the APERF/MPERF registers.
This prevents IPIs from being generated by read_msr()s as we are already
on the cpu of interest.
Ex: If cpupower is running on CPU 0 and we execute
read_msr(20, MSR_APERF, val) then,
read_msr(20, MSR_MPERF, val)
the msr module will generate an IPI from CPU 0 to CPU 20 to query
for the MSR_APERF and then the MSR_MPERF in separate IPIs.
This delay, caused by IPI latency, between reading the APERF and MPERF
registers may cause both of them to go out of sync.
The use of the per_cpu_schedule flag reduces the probability of this
from happening. It comes at the cost of a negligible increase in cpu
consumption caused by the migration of cpupower across each of the
cpus of the system.
Signed-off-by: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Move the needs_root variable into a sub-struct. This is in preparation
for adding a new flag for cpuidle_monitor.
Update all uses of the needs_root variable to reflect this change.
Signed-off-by: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Cpupower tool has set and info options which are being used only by
x86 machines. This patch removes support for these two subcommands
from cpupower utility for POWER. Thus, these two subcommands will now be
available only for intel.
This removes the ambiguous error message while using set option in case
of using non-intel systems.
Without this patch on a POWER system:
root@ubuntu:~# cpupower info
System does not support Intel's performance bias setting
root@ubuntu:~# cpupower set -b 10
Error setting perf-bias value on CPU
With this patch on a POWER box:
root@ubuntu:~# cpupower info
Subcommand not supported on POWER
Same result for set subcommand.
This patch does not affect results on a intel box.
Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
Acked-by: Thomas Renninger <trenn@suse.de>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
When building cpupower with clang, the following warning appears:
utils/idle_monitor/hsw_ext_idle.c:42:16: warning: initializer overrides
prior initialization of this subobject [-Winitializer-overrides]
.desc = N_("Processor Package C2"),
^~~~~~~~~~~~~~~~~~~~~~
./utils/helpers/helpers.h:25:33: note: expanded from macro 'N_'
#define N_(String) gettext_noop(String)
^~~~~~
./utils/helpers/helpers.h:23:30: note: expanded from macro
'gettext_noop'
#define gettext_noop(String) String
^~~~~~
utils/idle_monitor/hsw_ext_idle.c:41:16: note: previous initialization
is here
.desc = N_("Processor Package C9"),
^~~~~~~~~~~~~~~~~~~~~~
./utils/helpers/helpers.h:25:33: note: expanded from macro 'N_'
#define N_(String) gettext_noop(String)
^~~~~~
./utils/helpers/helpers.h:23:30: note: expanded from macro
'gettext_noop'
#define gettext_noop(String) String
^~~~~~
1 warning generated.
This appears to be a copy and paste or merge mistake because the name
and id fields both have PC9 in them, not PC2. Remove the second
assignment to fix the warning.
Fixes: 7ee767b69b ("cpupower: Add Haswell family 0x45 specific idle monitor to show PC8,9,10 states")
Link: https://github.com/ClangBuiltLinux/linux/issues/718
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
To set frequency on specific cpus using cpupower, following syntax can
be used :
cpupower -c #i frequency-set -f #f -r
While setting frequency using cpupower frequency-set command, if we use
'-r' option, it is expected to set frequency for all cpus related to
cpu #i. But it is observed to be missing the last cpu in related cpu
list. This patch fixes the problem.
Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
Reviewed-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
cpufreq driver creates sysfs file "scaling_boost_frequency" for platforms
which support boost frequency. Cpupower now prints boost frequencies
separately. For few x86 vendors who already have different way to get boost
frequency, will continue to use the existing logic. Rest of the platforms
will rely on "scaling_boost_frequency" file to display boost frequency.
Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
Signed-off-by: Shuah Khan <shuah@kernel.org>
Pull x86 cpu updates from Ingo Molnar:
"The main changes in this cycle were:
- Add support for the "Dhyana" x86 CPUs by Hygon: these are licensed
based on the AMD Zen architecture, and are built and sold in China,
for domestic datacenter use. The code is pretty close to AMD
support, mostly with a few quirks and enumeration differences. (Pu
Wen)
- Enable CPUID support on Cyrix 6x86/6x86L processors"
* 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
tools/cpupower: Add Hygon Dhyana support
cpufreq: Add Hygon Dhyana support
ACPI: Add Hygon Dhyana support
x86/xen: Add Hygon Dhyana support to Xen
x86/kvm: Add Hygon Dhyana support to KVM
x86/mce: Add Hygon Dhyana support to the MCA infrastructure
x86/bugs: Add Hygon Dhyana to the respective mitigation machinery
x86/apic: Add Hygon Dhyana support
x86/pci, x86/amd_nb: Add Hygon Dhyana support to PCI and northbridge
x86/amd_nb: Check vendor in AMD-only functions
x86/alternative: Init ideal_nops for Hygon Dhyana
x86/events: Add Hygon Dhyana support to PMU infrastructure
x86/smpboot: Do not use BSP INIT delay and MWAIT to idle on Dhyana
x86/cpu/mtrr: Support TOP_MEM2 and get MTRR number
x86/cpu: Get cache info and setup cache cpumap for Hygon Dhyana
x86/cpu: Create Hygon Dhyana architecture support file
x86/CPU: Change query logic so CPUID is enabled before testing
x86/CPU: Use correct macros for Cyrix calls
cpupower crashes on VMWare guests. The guests have the AMD PStateDef MSR
(0xC0010064 + state number) set to zero. As a result fid and did are zero
and the crash occurs because of a divide by zero (cof = fid/did). This
can be prevented by checking the enable bit in the PStateDef MSR before
calculating cof. By doing this the value of pstate[i] remains zero and
the value can be tested before displaying the active Pstates.
Check the enable bit in the PstateDef register for all supported families
and only print out enabled Pstates.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Stafford Horne <shorne@gmail.com>
Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
Pull cpupower utility fixes for 4.15-rc2 from Shuah Khan:
"This update consists of fixes to tool's handling of offline cpus.
The first patch fixes the tool to find information on the cpu it
is running on, instead of always looking for cpu0 and failing if
cpu0 happens to be offline.
The second patch fixes the incorrect check for offline cpu status."
* tag 'linux-cpupower-4.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux:
cpupower : Fix cpupower working when cpu0 is offline
cpupowerutils: bench - Fix cpu online check
cpuidle_monitor used to assume that cpu0 is always online which is not
a valid assumption on POWER machines. This patch fixes this by getting
the cpu on which the current thread is running, instead of always using
cpu0 for monitoring which may not be online.
Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
* pm-devfreq:
PM / devfreq: Define the constant governor name
PM / devfreq: Remove unneeded conditional statement
PM / devfreq: Show the all available frequencies
PM / devfreq: Change return type of devfreq_set_freq_table()
PM / devfreq: Use the available min/max frequency
Revert "PM / devfreq: Add show_one macro to delete the duplicate code"
PM / devfreq: Set min/max_freq when adding the devfreq device
* pm-tools:
tools/power/cpupower: add libcpupower.so.0.0.1 to .gitignore
tools/power/cpupower: Add 64 bit library detection
MAINTAINERS: add maintainer for tools/power/cpupower
cpupower: Fix no-rounding MHz frequency output
'cpupower frequency-info -ln' returns kHz values on systems with MHz range
minimum CPU frequency range. For example, on a 800MHz to 4.20GHz system
the command returns
hardware limits: 800000 MHz - 4.200000 GHz
The code that causes this error can be removed. The next else if clause
will handle the output correctly such that
hardware limits: 800.000 MHz - 4.200000 GHz
is displayed correctly.
[v2]: Remove two lines instead of fixing broken code.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Renninger <trenn@suse.com>
Cc: Stafford Horne <shorne@gmail.com>
Cc: Shuah Khan <shuah@kernel.org>
Reviewed-by: Stafford Horne <shorne@gmail.com>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
