Red Hat Bugzilla – Bug 474763
ondemand CPU frequency governor is too conservative
Last modified: 2015-01-04 17:30:48 EST
Description of problem:
Few days ago I updated my PC from F9 to F10. After that I found the system quite unresponsive. At first I was blaming the new software, but then I noticed the the CPU frequency was always at 50%, almost never going up, while in F9 was more "dynamic", i.e. was going up and down quickly.
Rebooting with the old F9 kernel was giving back the system and "cpufreq" responsiveness, that was the "old" kernel-188.8.131.52-41.
The machine has an AMD Athlon 64 X2 3800+ EE, which clocks at 1GHz, 1.8GHz and 2.0GHz, i.e. 50%, 90% and 100%.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Start some CPU intensive application, like "dosbox".
Wait and check the CPUfreq GNOME applet...
The CPU stays clocked at 50%.
The CPU should jump to 100%.
At the moment the PC is quite frustrating to use. For example "firefox" tab switching is painful slow, disk encryption is slow and, in general, as already remarked, the overall responsiveness is poor.
About "dosbox" test case, one interesting thing could be that "top" shows it as taking slightly less than 90% CPU, which may be the reason for not having the ondemand governor speeding up the clock.
On the other hand, if the governor is switched to performance and back to ondemand, the CPU clock goes to 100% and than back to 90% (not 50%) and it stays there until "dosbox" is closed.
The old kernel seems to switch the clock when the CPU load (of "dosbox") reaches 75%, so, maybe, some threshold is mis-tuned in the new one.
Sometimes, the ondemand governor can switch to higher clock, but this requires really a lot of load and quite a long time, which is not ideal for a desktop.
/sys/devices/system/cpu/cpu*/cpufreq/ondemand/up_threshold == 95
In F8 it's 31
The default looks insane, but you can change the value to tune it.
Thanks to pointing me in the right direction.
I checked kernel-184.108.40.206-41 from F9 and this one sets it to 80.
I tried 31, but this is definitely too low, I guess something around 70~80 should be OK.
One possibility seems to be to set the proper parameter for cpuspeed in /etc/sysconfig/cpuspeed
I was just wondering how should we go further with this issue.
Is some kernel default parameters tuning planned?
Should we change the component to "cpuspeed"?
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.