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.
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 kernel-utils-2.4-13.1.66
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.
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?
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.
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.