Bug 474763 - ondemand CPU frequency governor is too conservative
ondemand CPU frequency governor is too conservative
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Dave Jones
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-05 03:50 EST by Piergiorgio Sartor
Modified: 2015-01-04 17:30 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:10:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Piergiorgio Sartor 2008-12-05 03:50:08 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-2.6.27.5-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):
kernel-2.6.27.5-117

How reproducible:
Always.

Steps to Reproduce:
1.
Start some CPU intensive application, like "dosbox".
2.
Wait and check the CPUfreq GNOME applet...
  
Actual results:
The CPU stays clocked at 50%.

Expected results:
The CPU should jump to 100%.

Additional info:
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.
Comment 1 Chuck Ebbert 2008-12-08 15:03:29 EST
In F10:
/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.
Comment 2 Piergiorgio Sartor 2008-12-09 14:16:28 EST
Thanks to pointing me in the right direction.

I checked kernel-2.6.27.5-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

pg
Comment 3 Piergiorgio Sartor 2009-02-20 07:41:41 EST
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"?

Thanks,

pg
Comment 4 Bug Zapper 2009-11-18 05:20:49 EST
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Bug Zapper 2009-12-18 02:10:19 EST
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.

Note You need to log in before you can comment on or make changes to this bug.