cpufreqd forces minfreq to 100%
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cpufreqd (Ubuntu) |
New
|
Low
|
Unassigned |
Bug Description
== Comment: #0 - PAVAMAN SUBRAMANIYAM <email address hidden> - 2016-11-23 03:27:34 ==
---Problem Description---
cpufreq-set --freq option is not able to set the specific frequency value
Contact Information = <email address hidden>
---uname output---
Linux ltc-garri2 4.8.0-27-generic #29-Ubuntu SMP Thu Oct 20 21:01:16 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = P8
---Debugger---
A debugger is not configured
---Steps to Reproduce---
Install a P8 Open Power Hardware with Ubuntu 16.10 OS.
Then we are executing cpufreq-set which is a small tool which allows to modify cpufreq settings.
root@ltc-garri2:~# cpufreq-info -c 0
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to <email address hidden>, please.
analyzing CPU 0:
driver: powernv-cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3 4 5 6 7
CPUs which need to have their frequency coordinated by software: 0 1 2 3 4 5 6 7
maximum transition latency: 4294.55 ms.
hardware limits: 2.06 GHz - 4.02 GHz
available frequency steps: 4.02 GHz, 3.99 GHz, 3.96 GHz, 3.92 GHz, 3.89 GHz, 3.86 GHz, 3.82 GHz, 3.79 GHz, 3.76 GHz, 3.72 GHz, 3.69 GHz, 3.66 GHz, 3.62 GHz, 3.59 GHz, 3.56 GHz, 3.52 GHz, 3.49 GHz, 3.46 GHz, 3.42 GHz, 3.39 GHz, 3.36 GHz, 3.33 GHz, 3.29 GHz, 3.26 GHz, 3.23 GHz, 3.19 GHz, 3.16 GHz, 3.13 GHz, 3.09 GHz, 3.06 GHz, 3.03 GHz, 2.99 GHz, 2.96 GHz, 2.93 GHz, 2.89 GHz, 2.86 GHz, 2.83 GHz, 2.79 GHz, 2.76 GHz, 2.73 GHz, 2.69 GHz, 2.66 GHz, 2.63 GHz, 2.59 GHz, 2.56 GHz, 2.53 GHz, 2.49 GHz, 2.46 GHz, 2.43 GHz, 2.39 GHz, 2.36 GHz, 2.33 GHz, 2.29 GHz, 2.26 GHz, 2.23 GHz, 2.19 GHz, 2.16 GHz, 2.13 GHz, 2.09 GHz, 2.06 GHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 4.02 GHz and 4.02 GHz.
current CPU frequency is 4.02 GHz (asserted by call to hardware).
cpufreq stats: 4.02 GHz:100.00%, 3.99 GHz:0.00%, 3.96 GHz:0.00%, 3.92 GHz:0.00%, 3.89 GHz:0.00%, 3.86 GHz:0.00%, 3.82 GHz:0.00%, 3.79 GHz:0.00%, 3.76 GHz:0.00%, 3.72 GHz:0.00%, 3.69 GHz:0.00%, 3.66 GHz:0.00%, 3.62 GHz:0.00%, 3.59 GHz:0.00%, 3.56 GHz:0.00%, 3.52 GHz:0.00%, 3.49 GHz:0.00%, 3.46 GHz:0.00%, 3.42 GHz:0.00%, 3.39 GHz:0.00%, 3.36 GHz:0.00%, 3.33 GHz:0.00%, 3.29 GHz:0.00%, 3.26 GHz:0.00%, 3.23 GHz:0.00%, 3.19 GHz:0.00%, 3.16 GHz:0.00%, 3.13 GHz:0.00%, 3.09 GHz:0.00%, 3.06 GHz:0.00%, 3.03 GHz:0.00%, 2.99 GHz:0.00%, 2.96 GHz:0.00%, 2.93 GHz:0.00%, 2.89 GHz:0.00%, 2.86 GHz:0.00%, 2.83 GHz:0.00%, 2.79 GHz:0.00%, 2.76 GHz:0.00%, 2.73 GHz:0.00%, 2.69 GHz:0.00%, 2.66 GHz:0.00%, 2.63 GHz:0.00%, 2.59 GHz:0.00%, 2.56 GHz:0.00%, 2.53 GHz:0.00%, 2.49 GHz:0.00%, 2.46 GHz:0.00%, 2.43 GHz:0.00%, 2.39 GHz:0.00%, 2.36 GHz:0.00%, 2.33 GHz:0.00%, 2.29 GHz:0.00%, 2.26 GHz:0.00%, 2.23 GHz:0.00%, 2.19 GHz:0.00%, 2.16 GHz:0.00%, 2.13 GHz:0.00%, 2.09 GHz:0.00%, 2.06 GHz:0.00% (12)
Then try to set the specific frequency to be set for cpu0.
root@ltc-garri2:~# cpufreq-set -c 0 --freq 3.92GHz
root@ltc-garri2:~# echo $?
0
root@ltc-garri2:~# cat /sys/devices/
3258000
root@ltc-garri2:~# cat /sys/devices/
2061000
root@ltc-garri2:~# cat /sys/devices/
4023000
root@ltc-garri2:~# cat /sys/devices/
4023000
As can be seen the new frequency value is not getting set.
The /sys/devices/
Stack trace output:
no
Oops output:
no
Userspace tool common name: /usr/bin/
Userspace rpm: cpufrequtils
The userspace tool has the following bit modes: 64-bit
System Dump Info:
The system is not configured to capture a system dump.
Userspace tool obtained from project website: na
*Additional Instructions for <email address hidden>:
-Post a private note with access information to the machine that the bug is occuring on.
-Attach sysctl -a output output to the bug.
-Attach ltrace and strace of userspace application.
== Comment: #2 - SEETEENA THOUFEEK <email address hidden> - 2016-11-23 03:47:40 ==
Screening the issue.
== Comment: #11 - Akshay Adiga <email address hidden> - 2016-11-23 10:31:56 ==
Pavaman,
I figured out that this is not a cpufrequtils bug but this is because of way cpufreqd sets a profile.
1) It sets min, max and governor. No other tools is doing so. Hence if we try to change frequency policies with any tool, the scaling_min_freq still remains unchanged.
2) On installing cpufreqd, a init script /etc/init.
set by kernel ( which is ondemand)
You right the scaling_min_freq is being written by init scripts /etc/init.
/etc/cpufreq.conf tells cpufreqd to set both min and max to 100%.
[Profile]
name=Performance High
minfreq=100%
maxfreq=100%
policy=performance
#exec_post=echo 8 > /proc/acpi/
[/Profile]
As such cpufreqd is totally out of sync with the developements in the community and still relies on the acpi provided sensors to make the decision ( These are mentioned in .conf under [Rules]) . But as we donot have any of the files which it looks for, it falls back to set the first profile mentioned in the cpufreqd.conf .
To fix this issue, we change the configuration to set minfreq=0% , profile will look like this :
[Profile]
name=Performance High
minfreq=0%
maxfreq=100%
policy=performance
#exec_post=echo 8 > /proc/acpi/
[/Profile]
== Comment: #15 - Akshay Adiga <email address hidden> - 2016-11-23 23:23:11 ==
summary: |
- cpufreq-set --freq option is not able to set the specific frequency - value + cpufreqd forces minfreq to 100% |
affects: | cpufrequtils (Ubuntu) → cpufreqd (Ubuntu) |
Changed in cpufreqd (Ubuntu): | |
importance: | Undecided → Low |
Default Comment by Bridge