library versioning was broken:
libcpupower.so.0.0.1
libcpupower.so -> libcpupower.so.0.0.1
libcpupower.so.1 -> libcpupower.so.0.0.1
and is fixed by this patch to:
libcpupower.so.1.0.1
libcpupower.so -> libcpupower.so.1.0.1
libcpupower.so.1 -> libcpupower.so.1.0.1
Link: https://lore.kernel.org/r/20250307094334.39587-1-trenn@suse.de
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Shuah Khan <shuah@kernel.org>
This patch is also an issue report. get_cpu_topology will always save
into cpupower_topology a cores size of 0. The code to handle this looks
like it was commented out, and what is commented out is missing a curly
bracket.
https://elixir.bootlin.com/linux/v6.13.5/source/tools/power/cpupower/lib/cpupower.c#L206-L212
Inspiration was taken from psutil to implement this by querying
core_cpu_list. Instead of using a hashmap, I used a sorted array, and
counted the number of valid unique strings. The counting of this takes
place before the qsort for .pkg as the following code says it is
dependent on the order of that sort.
The previous code claimed Intel CPUs are not numbered correctly. I was
not able to reproduce that issue and removed that comment and the code.
This commit was tested with the libcpupower SWIG Python bindings and
performed correctly on 4 different setups. The most notable is the
Framework Intel laptop; a hybrid system of 4 P cores (8 threads) and 8 E
cores (8 threads).
The 4 setups: A 4 core virt-manager VM running Fedora 41 4c/4t (specs not
listed) was tested as a sanity test for VMs. A Lenovo Ryzen 7 Pro 7840HS
8c/16t. A Supermico Intel(R) Xeon(R) Gold 6330 CPU w/ 56c/112t with 2 CPU
sockets. A Framework 12th Gen Intel(R) Core(TM) i5-1240P with hybrid
cores.
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: AuthenticAMD
Model name: AMD Ryzen 7 PRO 7840HS w/ Radeon 780M Graphics
CPU family: 25
Model: 116
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 1
Stepping: 1
CPU(s): 112
On-line CPU(s) list: 0-111
Vendor ID: GenuineIntel
BIOS Vendor ID: Intel(R) Corporation
Model name: Intel(R) Xeon(R) Gold 6330 CPU @ 2.00GHz
BIOS Model name: Intel(R) Xeon(R) Gold 6330 CPU @ 2.00GHz CPU @ 2.0GHz
BIOS CPU family: 179
CPU family: 6
Model: 106
Thread(s) per core: 2
Core(s) per socket: 28
Socket(s): 2
Stepping: 6
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: GenuineIntel
Model name: 12th Gen Intel(R) Core(TM) i5-1240P
CPU family: 6
Model: 154
Thread(s) per core: 2
Core(s) per socket: 12
Socket(s): 1
Stepping: 3
Link: https://lore.kernel.org/r/20250305210901.24177-1-jwyatt@redhat.com
Signed-off-by: "John B. Wyatt IV" <jwyatt@redhat.com>
Signed-off-by: "John B. Wyatt IV" <sageofredondo@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
cmd_monitor() calls get_cpu_topology() to allocate memory for
cpu topology and fails to release in error legs.
Fix it to call cpu_topology_release() from error legs.
Link: https://lore.kernel.org/r/20250305225342.19447-2-skhan@linuxfoundation.org
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
In the case that we give a invalid command to idle_monitor for
monitoring, the execvp() will fail and thus go to the next line.
As a result, we'll see two differnt monitoring output. For
example, running `cpupower monitor -i 5 invalidcmd` which `invalidcmd`
is not executable.
Link: https://lore.kernel.org/r/20250220163846.2765-1-s921975628@gmail.com
Signed-off-by: Yiwei Lin <s921975628@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
If malloc returns NULL due to low memory, 'config' pointer can be NULL.
Add a check to prevent NULL dereference.
Link: https://lore.kernel.org/r/20250219122715.3892223-1-quic_zhonhan@quicinc.com
Signed-off-by: Zhongqiu Han <quic_zhonhan@quicinc.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
"tools/cpupower: display residency value in idle-info" added a new
function to cpuidle.h. This patch adds them to the bindings.
Link: https://lore.kernel.org/linux-pm/20240809083728.266697-1-aboorvad@linux.ibm.com/
Tested by compiling both libcpupower and the headers; running the test
script that does not use the functions as a basic sanity test.
Link: https://lore.kernel.org/r/20250108221852.30771-1-jwyatt@redhat.com
Signed-off-by: "John B. Wyatt IV" <jwyatt@redhat.com>
Signed-off-by: "John B. Wyatt IV" <sageofredondo@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Installs the .so and .py files generated by SWIG to system's site packages
directory. This allows the Python bindings to be used system wide. This
commit also includes documentation on setting up and installing the Python
bindings.
Link: https://lore.kernel.org/r/20241219012606.38963-1-jwyatt@redhat.com
Signed-off-by: "John B. Wyatt IV" <jwyatt@redhat.com>
Signed-off-by: "John B. Wyatt IV" <sageofredondo@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The amd-pstate section is grouped under boost, which isn't appropriate.
Adjust the indentation so that it is it's own section.
Link: https://lore.kernel.org/r/20241218191144.3440854-8-superm1@kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
When EPP has been enabled the hardware will autonomously change
frequencies on it's own and thus there is no latency with changing
from the kernel.
Avoid doing the maximum latency check when EPP is found. This will
apply to both amd-pstate and intel-pstate drivers.
Link: https://lore.kernel.org/r/20241218191144.3440854-7-superm1@kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The EPP value is useful for characterization of performance. Show
it in cpupower frequency-info output.
Link: https://lore.kernel.org/r/20241218191144.3440854-6-superm1@kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
When the amd-pstate is in use frequency is set by the hardware and
measured by the kernel through using the aperf and mperf registers.
There is no direct call to the hardware to indicate current frequency.
Detect that this feature is in use and skip the check.
Link: https://lore.kernel.org/r/20241218191144.3440854-5-superm1@kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The rankings are useful information to determine if the scheduler
is placing tasks appropriately for the hardware.
Link: https://lore.kernel.org/r/20241218191144.3440854-4-superm1@kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
When cpufreq_get_sysfs_value_from_table() is passed a table with
kernel strings that report 'enabled' or 'disabled' it always returns 0
because these can't cleanly convert to integers.
Explicitly look for enabled or disabled strings from the kernel to handle
this.
Link: https://lore.kernel.org/r/20241218191144.3440854-3-superm1@kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
print_duration() has a return; statement at the end of the function
that is not necessary as it's a void function.
Link: https://lore.kernel.org/r/20241218191144.3440854-2-superm1@kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Commit 'cpupower: Make TSC read per CPU for Mperf monitor' (c2adb1877b7)
changes TSC counter reads per cpu, but left time diff global (from start
of all cpus to end of all cpus), thus diff(time) is too large for a
cpu's tsc counting, resulting in far less than acutal TSC_Mhz and thus
`cpupower monitor` showing far less than actual cpu realtime frequency.
/proc/cpuinfo shows frequency:
cat /proc/cpuinfo | egrep -e 'processor' -e 'MHz'
...
processor : 171
cpu MHz : 4108.498
...
before fix (System 100% busy):
| Mperf || Idle_Stats
CPU| C0 | Cx | Freq || POLL | C1 | C2
171| 0.77| 99.23| 2279|| 0.00| 0.00| 0.00
after fix (System 100% busy):
| Mperf || Idle_Stats
CPU| C0 | Cx | Freq || POLL | C1 | C2
171| 0.46| 99.54| 4095|| 0.00| 0.00| 0.00
Fixes: c2adb1877b76 ("cpupower: Make TSC read per CPU for Mperf monitor")
Signed-off-by: He Rongguang <herongguang@linux.alibaba.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The is_valid flag should reflect the validity state of both
the XXX_start and XXX_stop functions. But the use of '=' in
XXX_stop overwrites the validity state set by XXX_start. This
commit changes '=' to '|=' in XXX_stop to preserve and combine
the validity state of XXX_start and XXX_stop.
Signed-off-by: wangfushuai <wangfushuai@baidu.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
After commit f79473ed9220 ("pm: cpupower: Makefile: Allow overriding
cross-compiling env params") we would fail to cross compile cpupower in
buildroot which uses the recipe at [1] where only the CROSS variable is
being set.
The issue here is the use of the lazy evaluation for all variables: CC,
LD, AR, STRIP, RANLIB, rather than just CROSS.
[1]:
https://git.buildroot.net/buildroot/tree/package/linux-tools/linux-tool-cpupower.mk.in
Fixes: f79473ed9220 ("pm: cpupower: Makefile: Allow overriding cross-compiling env params")
Reported-by: Florian Fainelli <florian.fainelli@broadcom.com>
Closes: https://lore.kernel.org/all/2bbabd2c-24ef-493c-a199-594e5dada3da@broadcom.com/
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Check whether xgettext and msgfmt are available on the system before
attempting to generate GNU gettext Language Translations.
In case of missing dependency, generate error message directing user
to install the necessary package.
Tested-by: John B. Wyatt IV <jwyatt@redhat.com>
Tested-by: John B. Wyatt IV <sageofredondo@gmail.com>
Suggested-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Siddharth Menon <simeddon@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Add a simple test to confirm and print out the cpu state.
Signed-off-by: "John B. Wyatt IV" <jwyatt@redhat.com>
Signed-off-by: "John B. Wyatt IV" <sageofredondo@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
This commit fixes a bad comment, removes an unneeded code block, and
catches a few more states that cpuidle_state_disable with the test
script. Part of the motivation for this commit was I kept forgetting to
use sudo.
Signed-off-by: "John B. Wyatt IV" <jwyatt@redhat.com>
Signed-off-by: "John B. Wyatt IV" <sageofredondo@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
A compile_commands.json file is used by the LSP in tools like VSCode and
Neovim to look up function and type information. The file is specific to
the state of the current system; add it to the gitignore.
Note: the kernel root's gitignore has a similar entry:
/compile_commands.json
I am not sure why they use '/' for a file as it is used for directories.
Signed-off-by: "John B. Wyatt IV" <jwyatt@redhat.com>
Signed-off-by: "John B. Wyatt IV" <sageofredondo@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Allow overriding the cross-comple env parameters to make it
easier for Yocto users. Then cross-compiler toolchains to build
cpupower with only two steps:
- source (toolchain path)/environment-setup-armv8a-poky-linux
- make
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Print out the config file path when fopen failed. It will be easy
for users to know where to create the file.
Since we are here, use strerror to drop the usage of perror.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The 'cpupower-set' tool has been enhanced with new features:
commit f2ab5557119a ("cpupower: Add EPP value change support")
commit df8776b03689 ("cpupower: Add support for amd_pstate mode change")
commit eb426fc6bdd6 ("cpupower: Add turbo-boost support in cpupower")
However, the corresponding manpage was never updated.
Add a basic description of these new options to the existing manpage.
Commit description updated to fix checkpatch errors: Shuah Khan
Signed-off-by: Tor Vic <torvic9@mailbox.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Add SPDX identifier to the gitignore. Remove the comment and .i file
since the file it references was removed in another patch. This patch
depends on Min-Hua Chen's 'pm: cpupower: rename raw_pylibcpupower.i'.
Signed-off-by: John B. Wyatt IV <jwyatt@redhat.com>
Signed-off-by: John B. Wyatt IV <sageofredondo@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The raw_pylibcpupower.i is removed unexpectedly after 'make mrproper'
We can reproduce the error by performing the following steps:
cd linux-next
make mrproper
cd tools/power/cpupower/bindings/python
make
We will get an error message:
make: *** No rule to make target 'raw_pylibcpupower.i', needed by 'raw_pylibcpupower_wrap.c'. Stop.
The root cause:
The *.i files are already used for pre-processor output files and
the kernel removes all the *.i files by 'make mrproper'.
That explains why the raw_pylibcpupower.i is removed by 'make mrproper'.
To fix it, Follow John's suggestion to rename raw_pylibcpupower.i to
raw_pylibcpupower.swg.
See:
https://www.swig.org/Doc4.2/SWIG.html
Reviewed-by: John B. Wyatt IV <jwyatt@redhat.com>
Reviewed-by: John B. Wyatt IV <sageofredondo@gmail.com>
Tested-by: John B. Wyatt IV <jwyatt@redhat.com>
Tested-by: John B. Wyatt IV <sageofredondo@gmail.com>
Signed-off-by: Min-Hua Chen <minhuadotchen@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Add error message to better explain to the user when SWIG and
python-config is missing from the path. Makefile was cleaned up
and unneeded elements were removed.
Suggested-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: John B. Wyatt IV <jwyatt@redhat.com>
Signed-off-by: John B. Wyatt IV <sageofredondo@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
This script demonstrates how to make use of, and tests, the bindings.
In the future, this script could become part of a larger test suite to
test the bindings and libcpupower.
Signed-off-by: John B. Wyatt IV <jwyatt@redhat.com>
Signed-off-by: John B. Wyatt IV <sageofredondo@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
SWIG is a tool packaged in Fedora and other distros that can generate
bindings from C and C++ code for several languages including Python,
Perl, and Go.
These bindings allows users to easily write scripts that use and extend
libcpupower's functionality. Currently, only Python is provided in the
makefile, but additional languages may be added if there is demand.
Added suggestions from Shuah Khan for the README and license discussion.
Note that while SWIG itself is GPL v3+ licensed; the resulting output,
the bindings code, is permissively licensed + the license of the .o
files. Please see
https://swig.org/legal.html and [1] for more details.
[1]
https://lore.kernel.org/linux-pm/Zqv9BOjxLAgyNP5B@hatbackup/
Suggested-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: John B. Wyatt IV <jwyatt@redhat.com>
Signed-off-by: John B. Wyatt IV <sageofredondo@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
There was a symbol listed in the powercap.h file that was not implemented.
Implement it with a stub return of 0.
Programs like SWIG require that functions that are defined in the
headers be implemented.
Fixes: c2294c1496b7 ("cpupower: Introduce powercap intel-rapl library and powercap-info command")
Suggested-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: John B. Wyatt IV <jwyatt@redhat.com>
Signed-off-by: John B. Wyatt IV <sageofredondo@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Invocation the tool built with the default settings fails:
$ cpupower
cpupower: error while loading shared libraries: libcpupower.so.1: cannot
open shared object file: No such file or directory
The issue is that Makefile puts the library to "/usr/lib64" dir for a 64
bit machine. This is wrong. According to the "File hierarchy standard
specification:
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standardhttps://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf
"/usr/lib<qual>" dirs are intended for alternative-format libraries
(e.g., "/usr/lib32" for 32-bit libraries on a 64-bit machine (optional)).
The utility is built for the current machine and doesn't handle
'CROSS_COMPILE' and 'ARCH' env variables. It also doesn't change bit
depth. So the result is always the same - binary for x86_64
architecture. Therefore the library should be put in the '/usr/lib'
dir regardless of the build options.
This is the case for all the distros that comply with the
'File Hierarchy Standard 3.0" by Linux Foundation. Most of the distros
comply with it. For example, one can check this by examining the
"/usr/lb64" dir on debian-based distros and find that it contains only
"/usr/lib64/ld-linux-x86-64.so.2". And examine that "/usr/lib" contains
both 32 and 64 bit code:
find /usr/lib -name "*.so*" -type f | xargs file | grep 32-bit
find /usr/lib -name "*.so*" -type f | xargs file | grep 64-bit
Fix the issue by changing library destination dir to "/usr/lib".
Signed-off-by: Roman Storozhenko <romeusmeister@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Execution of the 'make' command in the 'bench' subfolder causes the
following error:
$ make O=cpupower/build/ DESTDIR=cpupower/install/ -j8
" CC " cpupower/build//main.o
" CC " cpupower/build//parse.o
/bin/sh: 1: " CC "cpupower/build//system.o
CC : not found
make: *** [Makefile:21: cpupower/build//main.o] Error 127
make: *** Waiting for unfinished jobs....
/bin/sh: 1: CC : not found
/bin/sh: 1: CC : not found
make: *** [Makefile:21: cpupower/build//parse.o] Error 127
make: *** [Makefile:21: cpupower/build//system.o] Error 127
The makefile uses variables defined in the main project makefile and it
is not intended to run standalone. The reason is that 'bench' subproject
depends on the 'libcpupower' library, see the 'compile-bench' target in
the main makefile.
Add a check that prevents standalone execution of the 'bench' makefile.
Signed-off-by: Roman Storozhenko <romeusmeister@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
There is a type 'enum operation_mode_e' contains the display modes of
the 'monitor' subcommand. This type isn't used though, instead the
variable 'mode' is of a simple 'int' type.
Change 'mode' variable type from 'int' to 'enum operation_mode_e' in
order to improve compiler type checking.
Built and tested this with different monitor cmdline params. Everything
works as expected, that is nothing changed and no regressions encountered.
Signed-off-by: Roman Storozhenko <romeusmeister@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Remove not supported '-v' parameter from the cpupower's 'monitor'
command description.
There is a '-v' parameter described in cpupower's 'monitor' command man
page. It isn't supported at the moment, and perhaps has never been
supported. When I run the monitor with this parameter I get the
following:
$ sudo LD_LIBRARY_PATH=lib64/ bin/cpupower monitor -v
monitor: invalid option -- 'v'
invalid or unknown argument
$ sudo LD_LIBRARY_PATH=lib64/ bin/cpupower monitor -V
monitor: invalid option -- 'V'
invalid or unknown argument
Signed-off-by: Roman Storozhenko <romeusmeister@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Enhance cpupower build process description with the information on
building and installing the utility to the user defined directories
as well as with the information on the way of running the utility from
the custom defined installation directory.
Signed-off-by: Roman Storozhenko <romeusmeister@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Make "cpupower" building process more user friendly by adding 'help'
target to the main makefile. This target describes various build
and cleaning options available to the user.
Signed-off-by: Roman Storozhenko <romeusmeister@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Replace a dead reference link to a turbo boost technology description with
a reference to a root page of the technology on the Intel site, and add
another one, describing power management technology, which includes short
description of the turbo boost.
Signed-off-by: Roman Storozhenko <romeusmeister@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Update cpupower's P-State frequency calculation and reporting with AMD
Family 1Ah+ processors, when using the acpi-cpufreq driver. This is due
to a change in the PStateDef MSR layout in AMD Family 1Ah+.
Tested on 4th and 5th Gen AMD EPYC system
Signed-off-by: Ananth Narayan <Ananth.Narayan@amd.com>
Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
cpupower-frequency-info.1 man page type is incorrect for
related-cpus. Fix it.
utils/cpufreq-info.c
{"related-cpus", no_argument, NULL, 'r'},
{"affected-cpus", no_argument, NULL, 'a'},
Fixed changelog before applying:
Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Jan Kratochvil <jan@jankratochvil.net>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Allow user to specify outside CFLAGS values as make argument
Corrects an issue where CFLAGS is passed as a make argument for
cpupower, but bench's makefile does not inherit and append to them.
Signed-off-by: Stanley Chan <schan@cloudflare.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
This file was renamed from .txt to .rst and left a dangling reference.
Fix it.
Fixes: 151f4e2bdc7a ("docs: power: convert docs to ReST and rename to *.rst")
Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Len Brown <len.brown@intel.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Commit 4680b734e729 ("cpupower: Add Georgian translation") added
new language support. This change didn't add "ka" to Makefile
LANGUAGES variable. Add it now.
Reported-by: Temuri Doghonadze <temuri.doghonadze@gmail.com>
Reported-by: Zurab Kargareteli <zuraxt@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
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>
