Hide Forgot
I am running Oracle and a Java/JDBC application on a 6-Core (AMD Phenom X6) machine. In one operation, the single-threaded client issues a lot of database operations. After upgrading from Fedora 14 to 15, I saw a factor 4 slowdown in this operation. The reason is that the CPU frequency does not scale up. The scenario is as follows: During the operation, 2 cores are under load. Both are at about 45% user and 10% system. According to cpupower, both cores stay at 800 MHz: |Mperf CPU | C0 | Cx | Freq 0| 68.49| 31.51| 800 1| 60.29| 39.71| 768 2| 20.47| 79.53| 960 3| 8.09| 91.91| 1088 4| 1.76| 98.24| 768 5| 13.96| 86.04| 768 When I switch from the ondemand governor to the performance governor, both active cores run at 3600 MHz. Version-Release number of selected component (if applicable): cpupowerutils-009-0.3.p1.fc15.x86_64 cpuspeed-1.5-15.fc15.x86_64 kernel-2.6.38.8-32.fc15.x86_64 How reproducible: Always reproducible with my Oracle + Java app, but I can't supply that. I think that any client-server app which uses a lot of CPU time in addition to the inter-process communication should trigger the problem.
This seems to be an ondemand governor thing. Could it be the up/down thresholds have changed in the new kernel?
Are you still seeing this issue with the 2.6.40.6 kernel update?
Yes, definitely. With the database application mentioned, I get about 90,000 thingies per hour with ondemand, and 220,000 thingies per hour with performance. Actually, I have the impression that even a single CPU-bound process may be more affected by ondemand than it should be. As an example, I sometimes run a benchmark of the radiance ray tracer (see http://markjstock.org/pages/rad_bench.html) and I definitely get better results (on the order of 5%) with performance as opposed to ondemand. I don't think that was the case with older kernels.
Just checked the CPU-bound scenario (ray-tracer) again, and could not reproduce it with the current kernel. Please ignore the last paragraph of my previous comment.
Update: I'm still seeing this issue in Fedora 16.
On F16, the kernel on my machine does also not scale up, since ca. kernel-3.3.1-3.fc16.x86_64 (maybe even earlier). The system does not scale, output from /sys/devices/system/cpu/cpu?/cpufreq/scaling_m* shows always the lowest frequency. I had to downgrade to release kernel 3.1.0-7.fc16.x86_64 to get scaling again. Smolt Id is 5b8b26fb-f7c1-4a20-a773-24946944ac4c
Any news? I tried kernel-3.4.6-1.fc16.x86_64, which also does not scale frequency. I tried running with cpufreq.debug=7, but the only output is Aug 5 19:38:14 nepomuk kernel: [ 0.419350] ACPI: Requesting acpi_cpufreq Max frequency still is min frequency. Is anybody at all interested? Do I have to create my own BZ? Just to get attention?
# Mass update to all open bugs. Kernel 3.6.2-1.fc16 has just been pushed to updates. This update is a significant rebase from the previous version. Please retest with this kernel, and let us know if your problem has been fixed. In the event that you have upgraded to a newer release and the bug you reported is still present, please change the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. If you are not the original bug reporter and you still experience this bug, please file a new report, as it is possible that you may be seeing a different problem. (Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
I'm already on F17 with kernel 3.6.2-4.fc17.x86_64. The problem persists: 95k Treatments per hour scheduled with "ondemand" gouvernor, 245k with "performance".
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.