Red Hat Bugzilla – Bug 168755
cpuspeed does NOT work for AMD X2 processor with RHEL 4.1 x86-64
Last modified: 2008-08-02 19:40:33 EDT
Description of problem:
Sorry for listing this as a kernel issue but the cpuspeed program is not an
available selection on the component list for RHEL 4 update 1 ... and the
powernow-k8 kernel module (or lack of it) may be part of the problem.
I installed RHEL 4 update 1 on a new Athlon 64 X2 4600+ machine, ASUS A8N-E
motherboard (I downloaded and verified the CD's from redhat). Everything seemed
to work fine except performance was quite poor when running a numerical
simulation code. Research eventually led to the possibility that the AMD Cool
and Quiet option might be in use. /proc/cpuinfo listed the processor speeds as
1000.1 - bogomips as 1993.4 even when both CPU's were running under 100% load.
Execution times for the simulation code were 60% longer than on an AMD dual
processor 2800+ system - when they should have been faster.
Using the -h option to cpuspeed gave a help page listing the option of sending
SIGUSR1 to cpuspeed to force it to set the cpuspeed to maximum (cpuspeed was
running as a daemon as seen by using ps and the cpuspeed control file is in
/etc/init.d). Sending the USR1 signal to cpuspeed had the immediate effect of
changing the reported cpu frequency in /proc/cpuinfo to 2413.321. In addition,
further testing showed that the simulation codes run more than twice as fast as
they did previously.
Clearly, the cpuspeed daemon was not adjusting the cpu frequency for system load
in this case.
Note that the powernow-k8 kernel module is not available - I don't know if it is
needed for cpuspeed to function correctly. It may also be that cpuspeed is just
not interpreting the system load correctly on the dual core X2 processors and
thus never scaling up the cpu frequency. In any case, this is a non-obvious and
non-trivial issue in that computer performance is severely curtailed by this bug
without the user being aware of it - other than some apparently lacklustre
performance numbers (which could have many explanations depending on the code).
Version-Release number of selected component (if applicable):
Always on my system - processor speed is set to minimum unless forced to a
specific value by sending SIGUSR1 or 2 to the cpuspeed daemon.
Steps to Reproduce:
1. Start the computer - it always happens
AMD Athlon 64 X2 4600+ processor
ASUS A8N-E motherboard
2 Gb RAM
250Gb SATAII HD
ASUS Nvidia 6200 128Mb
RHEL 4.1 x86-64 + all updates from up2date
Actual results: CPU speed is stuck at 1000.1 MHz
Expected results: CPU speed should scale with system load
I believe all of the required files in
appear to be present.
hmmm. bummer. as a temporary workaround, i guess you could disable cpuspeed and
set the /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq to the max value.
I can give you more detail for this if you want...
For U2, we've updated the powernow-k8 module in the kernel. I'm not sure if
there were any changes for cpuspeed. The updated kernel, which i think is worth
a try is at: http://people.redhat.com/~jbaron/rhel4/ thanks.
also, cpuspeed is part of the kernel-utils package:
$ rpm -qf /usr/sbin/cpuspeed
In case anyone else is browsing this thread. Disabling cpuspeed using
chkconfig --level 2345 cpuspeed off
and setting the frequencies in
to the maximum values for the CPU - results in everything running at full speed.
I set the values in the apprpriate files by sending cpuspeed the -USR1 signal
(force to maximum speed) before I shut it off - cpuspeed or the kernel changes
the values in the files so I didn't have to manually edit them.
what governor is being used?
if the governor is "userspace", cpuspeed will behave as configured in
perhaps it would be better to ship RHEL configured for performance instead of
configure for energy efficiency and let the user configure for efficiency if
core:~> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
# uncomment this and set to the name of your CPUFreq module
# Let background (nice) processes speed up the cpu
# Add your favorite options here
#OPTS="$OPTS -s 0 -i 10 -r"
# uncomment and modify this to check the state of the AC adapter
#OPTS="$OPTS -a /proc/acpi/ac_adapter/*/state"
# uncomment and modify this to check the system temperature
#OPTS="$OPTS -t /proc/acpi/thermal_zone/*/temperature 75"
These are the files as they are currently on the machine. I don't know if Update
2 to RHEL 4 would have changed any of the files since I filed the bug.
As I said in the original bug report - even with 2 processes running using 100%
of available CPU for both cores - cpufreq did not increase the clock speed to
2.4GHz - it stayed at 1GHz. Even with a process using 100% of a single core -
cpufreq should up the processor clock speed and it did not.
If cpufreq operated correctly and changed the processor speed appropriately
depending on system load this bug would not have been filed.
by default, cpuspeed gets started by init (/etc/rc.d/rc*.d/S06cpuspeed) even
though its config file (/etc/cpuspeed.conf) isnt set up properly on a fresh
RHEL4 install. this causes a fresh RHEL4 install to run slow as a dog on AMD64
because speed scaling (powernow-k7 and powernow-k8) isnt working properly.
cpuspeed should not be started by default, rather it should be disabled after a
fresh RHEL4 install. the user can then set up /etc/cpuspeed.conf as they desire
and use the runlevel editor to enable cpuspeed.
also some alternative options:
(1) provide a default /etc/cpuspeed.conf that is pre-configured to run at the
max cpu speed, or at least one that works properly (even if not optimally) for
all AMD64 systems
(2) make the 'performance' governor the default governor
Is this still a problem with the latest RHEL4 kernels and kernel-utils? There's
been a big overhaul of cpuspeed for rhel5, some of which could likely be ported
back to rhel4, if need be...
No activity in 4+ months and no word from the original poster in over a year,
closing out bug.