Bug 168755 - cpuspeed does NOT work for AMD X2 processor with RHEL 4.1 x86-64
cpuspeed does NOT work for AMD X2 processor with RHEL 4.1 x86-64
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel-utils (Show other bugs)
4.0
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Jarod Wilson
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-19 23:44 EDT by david
Modified: 2008-08-02 19:40 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-04 17:38:14 EDT
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 david 2005-09-19 23:44:44 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):
RHEL 4.1 


How reproducible:
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
2.
3.

AMD Athlon 64 X2 4600+ processor 
ASUS A8N-E motherboard
2 Gb RAM
250Gb SATAII HD
DVDRW
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


Additional info: 
I believe all of the required files in
/sys/devices/system/cpu/cpu1/cpufreq
and
/sys/devices/system/cpu/cpu0/cpufreq
appear to be present.
Comment 1 Jason Baron 2005-09-20 15:58:26 EDT
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.
Comment 2 Jason Baron 2005-09-20 15:59:53 EDT
also, cpuspeed is part of the kernel-utils package:

$ rpm -qf  /usr/sbin/cpuspeed
kernel-utils-2.4-13.1.66
Comment 3 david 2005-09-28 15:35:40 EDT
In case anyone else is browsing this thread. Disabling cpuspeed using 
chkconfig --level 2345 cpuspeed off
and setting the frequencies in
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq and
/sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq 
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. 
Comment 4 Brian Maly 2006-02-28 10:47:47 EST
what governor is being used? 

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

if the governor is "userspace", cpuspeed will behave as configured in
/etc/cpuspeed.conf

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
desired?
Comment 5 david 2006-02-28 11:41:38 EST
core:~> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
userspace performance

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
userspace

more /etc/cpuspeed.conf
VMAJOR=1
VMINOR=1

# uncomment this and set to the name of your CPUFreq module
#DRIVER="powernow-k7"

# Let background (nice) processes speed up the cpu
OPTS="$OPTS -n"

# 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. 
Comment 6 Brian Maly 2006-03-13 16:12:41 EST
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. 

Comment 7 Brian Maly 2006-03-14 16:01:23 EST
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
Comment 8 Jarod Wilson 2007-01-24 10:17:25 EST
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...
Comment 9 Jarod Wilson 2007-06-04 17:38:14 EDT
No activity in 4+ months and no word from the original poster in over a year,
closing out bug.

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