| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intel_pstate kselftest expects that the output of
`cpupower frequency-info -l | tail -1 | awk ' { print $1 } '`
to get frequency limits. This does not work after the following two
changes.
- 562e5f1a3: rework the "cpupower frequency-info" command
(Jacob Tanenbaum) removed parsable limit output
- ce512b840: Do not analyse offlined cpus
(Thomas Renninger) added newline to break limit parsing more
This change preserves human readable output if wanted as well as
parsable output for scripts/tests.
Cc: Thomas Renninger <trenn@suse.com>
Cc: "Shreyas B. Prabhu" <shreyas@linux.vnet.ibm.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: linux-pm@vger.kernel.org
Signed-off-by: Stafford Horne <shorne@gmail.com>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the following build error by including limits.h -
utils/cpufreq-info.c: In function ‘get_latency’:
utils/cpufreq-info.c:437:29: error: ‘UINT_MAX’ undeclared (first use in
this function)
if (!latency || latency == UINT_MAX) {
^
Signed-off-by: Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
Fixes: e98f033f94f3 (cpupower: fix how "cpupower frequency-info" interprets latency)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
the intel-pstate driver does not support the ondemand governor and does not
have a valid value in
/sys/devices/system/cpu/cpu[x]/cpufreq/cpuinfo_transition_latency. The
intel-pstate driver sets cpuinfo_transition_latency to CPUFREQ_ETERNAL (-1),
the value written into cpuinfo_transition_latency is defind as an unsigned
int so checking the read value against max unsigned int will determine if the
value is valid.
Signed-off-by: Jacob Tanenbaum <jtanenba@redhat.com>
Signed-off-by: Thomas Renninger <trenn@suse.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this patch makes two changes to the way that "cpupower
frequancy-info" operates
1. make it so that querying individual values always returns a
message to the user
currently cpupower frequency info doesn't return anything to the user when
querying an individual value cannot be returned
[root@amd-dinar-09 cpupower]# cpupower -c 4 frequency-info -d
analyzing CPU 4:
[root@amd-dinar-09 cpupower]#
I added messages so that each query prints a message to the terminal
[root@amd-dinar-09 cpupower]# ./cpupower -c 4 frequency-info -d
analyzing CPU 4:
no or unknown cpufreq driver is active on this CPU
[root@amd-dinar-09 cpupower]#
(this is just one example)
2. change debug_output_one() to use the functions already provided
by cpufreq-info.c to query individual values of interest.
Signed-off-by: Jacob Tanenbaum <jtanenba@redhat.com>
Signed-off-by: Thomas Renninger <trenn@suse.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| |
|
|
|
|
|
|
|
|
| |
Use sysfs_is_cpu_online(cpu) instead of cpufreq_cpu_exists(cpu) to detect offlined cpus.
Re-arrange printfs slightly to have a consistent output even if you have multiple CPUs
as output and even if offlined cores are in between.
Signed-off-by: Thomas Renninger <trenn@suse.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch tries to creates a common structure initialization
within the cpupower tool.
Previously the ``struct option`` was initialized
using `designated initializer` technique which was
not needed. There were conflicting initialization methods seen with
bench/main.c & others.
Signed-off-by: Sriram Raghunathan <sriram@marirs.net.in>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The command "cpupower frequency-info" can be used when using cpupower to
monitor and test processor behaviour to determine if the processor is
behaving as expected. This data can be compared to the output of
/proc/cpuinfo or the output of
/sys/devices/system/cpu/cpuX/cpufreq/scaling_available_frequencies
to determine if the cpu is in an expected state.
When doing this I noticed comparison test failures due to the way the
data is displayed in cpupower. For example,
[root@intel-s3e37-02 cpupower]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
2262000 2261000 2128000 1995000 1862000 1729000 1596000 1463000 1330000
1197000 1064000
compared to
[root@intel-s3e37-02 cpupower]# cpupower frequency-info
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 10.0 us.
hardware limits: 1.06 GHz - 2.26 GHz
available frequency steps: 2.26 GHz, 2.26 GHz, 2.13 GHz, 2.00 GHz, 1.86 GHz, 1.73 GHz, 1.60 GHz, 1.46 GHz, 1.33 GHz, 1.20 GHz, 1.06 GHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance
current policy: frequency should be within 1.06 GHz and 2.26 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 2.26 GHz (asserted by call to hardware).
boost state support:
Supported: yes
Active: yes
shows very different values for the available frequency steps. The cpupower
output rounds off values at 2 decimal points and this causes problems with
test scripts. For example, with the data above,
1.064 is 1.06
1.197 is 1.20
1.596 is 1.60
1.995 is 2.00
2.128 is 2.13
and most confusingly,
2.261 is 2.26
2.262 is 2.26
Truncating these values serves no real purpose other than making the output
pretty. Since the default has been to round off these values I am adding
a -n/--no-rounding option to the cpupower utility that will display the
data without rounding off the still significant digits.
After patch,
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 10.000 us.
hardware limits: 1.064000 GHz - 2.262000 GHz
available frequency steps: 2.262000 GHz, 2.261000 GHz, 2.128000 GHz, 1.995000 GHz, 1.862000 GHz, 1.729000 GHz, 1.596000 GHz, 1.463000 GHz, 1.330000 GHz, 1.197000 GHz, 1.064000 GHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance
current policy: frequency should be within 1.064000 GHz and 2.262000 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 2.262000 GHz (asserted by call to hardware).
boost state support:
Supported: yes
Active: yes
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
[rjw: Subject]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| |
|
|
|
|
|
| |
Instead of printing something non-formatted to stdout, call
man(1) to show the man page for the proper subcommand.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the last piece missing from turbostat (if called with -v).
It shows on Intel machines supporting Turbo Boost how many cores
have to be active/idle to enter which boost mode (frequency).
Whether the HW really enters these boost modes can be verified via
./cpupower monitor.
Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: lenb@kernel.org
CC: linux@dominikbrodowski.net
CC: cpufreq@vger.kernel.org
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
| |
|
|
| |
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
|
|
CPU power consumption vs performance tuning is no longer
limited to CPU frequency switching anymore: deep sleep states,
traditional dynamic frequency scaling and hidden turbo/boost
frequencies are tied close together and depend on each other.
The first two exist on different architectures like PPC, Itanium and
ARM, the latter (so far) only on X86. On X86 the APU (CPU+GPU) will
only run most efficiently if CPU and GPU has proper power management
in place.
Users and Developers want to have *one* tool to get an overview what
their system supports and to monitor and debug CPU power management
in detail. The tool should compile and work on as many architectures
as possible.
Once this tool stabilizes a bit, it is intended to replace the
Intel-specific tools in tools/power/x86
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
