<feed xmlns='http://www.w3.org/2005/Atom'>
<title>wireguard-linux/tools/power/cpupower/utils, branch update-toolchain</title>
<subtitle>WireGuard for the Linux kernel</subtitle>
<id>https://git.zx2c4.com/wireguard-linux/atom/tools/power/cpupower/utils?h=update-toolchain</id>
<link rel='self' href='https://git.zx2c4.com/wireguard-linux/atom/tools/power/cpupower/utils?h=update-toolchain'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/'/>
<updated>2024-06-20T16:08:08Z</updated>
<entry>
<title>cpupower: Change the var type of the 'monitor' subcommand display mode</title>
<updated>2024-06-20T16:08:08Z</updated>
<author>
<name>Roman Storozhenko</name>
<email>romeusmeister@gmail.com</email>
</author>
<published>2024-06-20T15:57:23Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=3e1f12c26646eb0ad67d3eaefd32f765997da6a8'/>
<id>urn:sha1:3e1f12c26646eb0ad67d3eaefd32f765997da6a8</id>
<content type='text'>
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 &lt;romeusmeister@gmail.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tools/power/cpupower: Fix Pstate frequency reporting on AMD Family 1Ah CPUs</title>
<updated>2024-05-28T15:22:57Z</updated>
<author>
<name>Dhananjay Ugwekar</name>
<email>Dhananjay.Ugwekar@amd.com</email>
</author>
<published>2024-04-30T08:37:06Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=43cad521c6d228ea0c51e248f8e5b3a6295a2849'/>
<id>urn:sha1:43cad521c6d228ea0c51e248f8e5b3a6295a2849</id>
<content type='text'>
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 &lt;Ananth.Narayan@amd.com&gt;
Signed-off-by: Dhananjay Ugwekar &lt;Dhananjay.Ugwekar@amd.com&gt;
Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>cpupower: Fix cpuidle_set to accept only numeric values for idle-set operation.</title>
<updated>2023-07-18T22:07:08Z</updated>
<author>
<name>Likhitha Korrapati</name>
<email>likhitha@linux.ibm.com</email>
</author>
<published>2023-07-14T09:40:21Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=99481d2195bfd13a663904e6014887abf46b57c7'/>
<id>urn:sha1:99481d2195bfd13a663904e6014887abf46b57c7</id>
<content type='text'>
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 &lt;latha@linux.vnet.ibm.com&gt;
Signed-off-by: Likhitha Korrapati &lt;likhitha@linux.ibm.com&gt;
Tested-by: Pavithra Prakash &lt;pavrampu@linux.vnet.ibm.com&gt;
Reviewed-by: Rick Lindsley &lt;ricklind@linux.vnet.ibm.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>cpupower: Add turbo-boost support in cpupower</title>
<updated>2023-07-18T22:07:01Z</updated>
<author>
<name>Wyes Karny</name>
<email>wyes.karny@amd.com</email>
</author>
<published>2023-06-19T19:05:03Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=eb426fc6bdd6b731cbc0900f24a8c5fba10a7631'/>
<id>urn:sha1:eb426fc6bdd6b731cbc0900f24a8c5fba10a7631</id>
<content type='text'>
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 &lt;ray.huang@amd.com&gt;
Reviewed-by: Gautham R. Shenoy &lt;gautham.shenoy@amd.com&gt;
Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Wyes Karny &lt;wyes.karny@amd.com&gt;
Tested-by: Perry Yuan &lt;Perry.Yuan@amd.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>cpupower: Add support for amd_pstate mode change</title>
<updated>2023-07-18T22:06:56Z</updated>
<author>
<name>Wyes Karny</name>
<email>wyes.karny@amd.com</email>
</author>
<published>2023-06-19T19:05:02Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=df8776b03689987e3239f3c010b6dc6ab4185d30'/>
<id>urn:sha1:df8776b03689987e3239f3c010b6dc6ab4185d30</id>
<content type='text'>
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 &lt;ray.huang@amd.com&gt;
Reviewed-by: Gautham R. Shenoy &lt;gautham.shenoy@amd.com&gt;
Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Wyes Karny &lt;wyes.karny@amd.com&gt;
Tested-by: Perry Yuan &lt;Perry.Yuan@amd.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>cpupower: Add EPP value change support</title>
<updated>2023-07-18T22:06:49Z</updated>
<author>
<name>Wyes Karny</name>
<email>wyes.karny@amd.com</email>
</author>
<published>2023-06-19T19:05:01Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=f2ab5557119a5ccd0ceaf7ecdca00ab782cd76c5'/>
<id>urn:sha1:f2ab5557119a5ccd0ceaf7ecdca00ab782cd76c5</id>
<content type='text'>
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 &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Wyes Karny &lt;wyes.karny@amd.com&gt;
Tested-by: Perry Yuan &lt;Perry.Yuan@amd.com&gt;
Acked-by: Huang Rui &lt;ray.huang@amd.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>cpupower: Recognise amd-pstate active mode driver</title>
<updated>2023-07-18T22:06:36Z</updated>
<author>
<name>Wyes Karny</name>
<email>wyes.karny@amd.com</email>
</author>
<published>2023-06-19T19:04:59Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=a1cf97c2d43ae51f3de091d51adff6b70a5cd55c'/>
<id>urn:sha1:a1cf97c2d43ae51f3de091d51adff6b70a5cd55c</id>
<content type='text'>
amd-pstate active mode driver name is "amd-pstate-epp". Use common
prefix for string matching condition to recognise amd-pstate active mode
driver.

Reviewed-by: Gautham R. Shenoy &lt;gautham.shenoy@amd.com&gt;
Signed-off-by: Wyes Karny &lt;wyes.karny@amd.com&gt;
Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Tested-by: Perry Yuan &lt;Perry.Yuan@amd.com&gt;
Acked-by: Huang Rui &lt;ray.huang@amd.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>cpupower: Make TSC read per CPU for Mperf monitor</title>
<updated>2023-05-08T16:46:49Z</updated>
<author>
<name>Wyes Karny</name>
<email>wyes.karny@amd.com</email>
</author>
<published>2023-05-04T06:25:44Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=c2adb1877b76fc81ae041e1db1a6ed2078c6746b'/>
<id>urn:sha1:c2adb1877b76fc81ae041e1db1a6ed2078c6746b</id>
<content type='text'>
System-wide TSC read could cause a drift in C0 percentage calculation.
Because if first TSC is read and then one by one mperf is read for all
cpus, this introduces drift between mperf reading of later CPUs and TSC
reading.  To lower this drift read TSC per CPU and also just after mperf
read.  This technique improves C0 percentage calculation in Mperf monitor.

Before fix: (System 100% busy)

              | Mperf              || RAPL        || Idle_Stats
 PKG|CORE| CPU| C0   | Cx   | Freq  || pack | core  || POLL | C1   | C2
   0|   0|   0| 87.15| 12.85|  2695||168659003|3970468||  0.00|  0.00| 0.00
   0|   0| 256| 84.62| 15.38|  2695||168659003|3970468||  0.00|  0.00| 0.00
   0|   1|   1| 87.15| 12.85|  2695||168659003|3970468||  0.00|  0.00| 0.00
   0|   1| 257| 84.08| 15.92|  2695||168659003|3970468||  0.00|  0.00| 0.00
   0|   2|   2| 86.61| 13.39|  2695||168659003|3970468||  0.00|  0.00| 0.00
   0|   2| 258| 83.26| 16.74|  2695||168659003|3970468||  0.00|  0.00| 0.00
   0|   3|   3| 86.61| 13.39|  2695||168659003|3970468||  0.00|  0.00| 0.00
   0|   3| 259| 83.60| 16.40|  2695||168659003|3970468||  0.00|  0.00| 0.00
   0|   4|   4| 86.33| 13.67|  2695||168659003|3970468||  0.00|  0.00| 0.00
   0|   4| 260| 83.33| 16.67|  2695||168659003|3970468||  0.00|  0.00| 0.00
   0|   5|   5| 86.06| 13.94|  2695||168659003|3970468||  0.00|  0.00| 0.00
   0|   5| 261| 83.05| 16.95|  2695||168659003|3970468||  0.00|  0.00| 0.00
   0|   6|   6| 85.51| 14.49|  2695||168659003|3970468||  0.00|  0.00| 0.00

After fix: (System 100% busy)

             | Mperf              || RAPL        || Idle_Stats
 PKG|CORE| CPU| C0   | Cx   | Freq  || pack | core  || POLL | C1   | C2
   0|   0|   0| 98.03|  1.97|  2415||163295480|3811189||  0.00|  0.00| 0.00
   0|   0| 256| 98.50|  1.50|  2394||163295480|3811189||  0.00|  0.00| 0.00
   0|   1|   1| 99.99|  0.01|  2401||163295480|3811189||  0.00|  0.00| 0.00
   0|   1| 257| 99.99|  0.01|  2375||163295480|3811189||  0.00|  0.00| 0.00
   0|   2|   2| 99.99|  0.01|  2401||163295480|3811189||  0.00|  0.00| 0.00
   0|   2| 258|100.00|  0.00|  2401||163295480|3811189||  0.00|  0.00| 0.00
   0|   3|   3|100.00|  0.00|  2401||163295480|3811189||  0.00|  0.00| 0.00
   0|   3| 259| 99.99|  0.01|  2435||163295480|3811189||  0.00|  0.00| 0.00
   0|   4|   4|100.00|  0.00|  2401||163295480|3811189||  0.00|  0.00| 0.00
   0|   4| 260|100.00|  0.00|  2435||163295480|3811189||  0.00|  0.00| 0.00
   0|   5|   5| 99.99|  0.01|  2401||163295480|3811189||  0.00|  0.00| 0.00
   0|   5| 261|100.00|  0.00|  2435||163295480|3811189||  0.00|  0.00| 0.00
   0|   6|   6|100.00|  0.00|  2401||163295480|3811189||  0.00|  0.00| 0.00
   0|   6| 262|100.00|  0.00|  2435||163295480|3811189||  0.00|  0.00| 0.00

Cc: Thomas Renninger &lt;trenn@suse.com&gt;
Cc: Shuah Khan &lt;shuah@kernel.org&gt;
Cc: Dominik Brodowski &lt;linux@dominikbrodowski.net&gt;

Fixes: 7fe2f6399a84 ("cpupowerutils - cpufrequtils extended with quite some features")
Signed-off-by: Wyes Karny &lt;wyes.karny@amd.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>cpupower: rapl monitor - shows the used power consumption in uj for each rapl domain</title>
<updated>2022-11-30T23:48:34Z</updated>
<author>
<name>Thomas Renninger</name>
<email>trenn@suse.de</email>
</author>
<published>2022-11-23T11:18:10Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=8c37df3d635eac64a8fbb4b26672fb881e0cb673'/>
<id>urn:sha1:8c37df3d635eac64a8fbb4b26672fb881e0cb673</id>
<content type='text'>
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 &lt;trenn@suse.de&gt;
CC: Zhang Rui &lt;rui.zhang@intel.com&gt;
CC: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>cpupower: Introduce powercap intel-rapl library and powercap-info command</title>
<updated>2022-11-30T23:48:28Z</updated>
<author>
<name>Thomas Renninger</name>
<email>trenn@suse.de</email>
</author>
<published>2022-11-23T11:18:09Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=c2294c1496b7169d5b14c2fa27526ba35da9f5ac'/>
<id>urn:sha1:c2294c1496b7169d5b14c2fa27526ba35da9f5ac</id>
<content type='text'>
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
-&gt; pack (age-0)
intel-rapl/intel-rapl:0/intel-rapl:0:0
-&gt; core
intel-rapl/intel-rapl:0/intel-rapl:0:1
-&gt; uncore

Missing ones on my system are:
intel-rapl-mmio/intel-rapl-mmio:0
-&gt; pack (age-0)

intel-rapl/intel-rapl:1
-&gt; 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 &lt;trenn@suse.de&gt;
CC: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
</entry>
</feed>
