Bug 168755

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.