Red Hat Bugzilla – Bug 317971
System is kept throttled down although one core is fully utlized
Last modified: 2008-08-21 09:50:05 EDT
Description of problem:
A system with 8 cores runs multiple programs, of which one has one thread
utilizing 1 core with 100%.
The overall CPU usage of all 8 cores is at about 50% when the system is scaled
down by cpuspeed to 1/3 of the capacity.
However, the 1 thread needs more processing power to get the work done, so we
were forced to disable cpuspeed. The overall usage is than just 25%, but the one
thread receives enough CPU speed to get its work done.
Version-Release number of selected component (if applicable): 1.2.1
Steps to Reproduce:
1. run a single-threaded process which utilizes one core by 100%
2. watch cat /proc/cpuinfo and see that the system is kept scaled down
it would be perfect if the one core/cpu is scaled up if it's fully utilized.
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 8220
power management: ts fid vid ttp tm stc
Addition: I just tried to change the default config to use the userspace
governor instead of ondemand scaling. With the userspace governor I get far
better results and all threads seem to receive the processing power needed.
If the ondemand scaling doesn't work out ins uch installations, the default
should perhaps be changed to userspace.
Huh, ondemand seems to work quite well for me/does the right thing in all
multi-core cases I've seen. However, that's been predominantly with Intel
processors using the acpi-cpufreq driver. I'll see if I can manage to reproduce
the problem on a multi-core AMD system (which use the powernow-k8 driver). Cores
should all scale together, but each cpu package should scale independently.
Could be an accounting issue.
Actually, this could well be something we've fixed for 5.1... I'm assuming
you're running a 5.0 kernel (2.6.18-8.something). Can I have you try a 5.1 beta
kernel first, before I go chasing this down?
You can get 'em here:
At the moment, 52.el5 is the latest, please give that a shot and let me know if
the problem persists.
Any improvement with a 5.1 kernel? If not, how about with a 5.2 beta kernel?
Ah, and this is actually a kernel issue, not a cpuspeed issue, since its the
in-kernel ondemand governor we're talking about, not the cpuspeed daemon (which
only comes into play if using the 'userspace' governor).
Closing bug due to lack of any response for 10 months.