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 How reproducible: always 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 Actual results: scaled down Expected results: it would be perfect if the one core/cpu is scaled up if it's fully utilized. Additional info: Processors are 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: http://people.redhat.com/dzickus/el5/ 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.