Description of problem: System is mostly idle, firefox open with several tabs. Default settings: Top causes for wakeups: 30.7% (150.3) <kernel core> : hrtimer_start_expires (tick_sched_timer) 30.5% (149.7) npviewer.bin : hrtimer_start_expires (hrtimer_wakeup) 10.7% ( 52.4) firefox : futex_wait (hrtimer_wakeup) 7.4% ( 36.5) firefox : hrtimer_start_expires (hrtimer_wakeup) 5.7% ( 28.1) <interrupt> : ata_piix, eth0 2.9% ( 14.2) <kernel core> : hrtimer_start (tick_sched_timer) 2.0% ( 10.0) <kernel core> : mod_timer (ehci_watchdog) Suggestion: Enable the ondemand cpu speed governor for all processors via: echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor Top causes for wakeups: 76.6% (979.5) <kernel core> : hrtimer_start_expires (tick_sched_timer) 11.3% (144.5) npviewer.bin : hrtimer_start_expires (hrtimer_wakeup) 4.2% ( 53.8) firefox : futex_wait (hrtimer_wakeup) 2.6% ( 32.7) firefox : hrtimer_start_expires (hrtimer_wakeup) system becomes very sluggish. Is this expected? Version-Release number of selected component (if applicable): 2.6.29.1-30.fc10.i686 How reproducible: Everytime - immediately.
Similar with "userspace" governor. # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 3 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping : 4 cpu MHz : 3000.000 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pebs bts pni dtes64 monitor ds_cpl cid xtpr bogomips : 5985.01 clflush size : 64 power management: processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 3 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping : 4 cpu MHz : 3000.000 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 apicid : 1 initial apicid : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pebs bts pni dtes64 monitor ds_cpl cid xtpr bogomips : 5984.72 clflush size : 64 power management: Hyperthreaded P4.
https://qa.mandriva.com/show_bug.cgi?id=43155 seems to indicate possible issues with interaction with p4_clockmod. I tried adding p4_clockmod to /etc/modprobe.d/blacklist, but it still gets loaded on boot. No idea what. Can't remove it: # lsmod | grep p4 p4_clockmod 4184 1 [root@orca ~]# modprobe -r p4_clockmod FATAL: Module p4_clockmod is in use.
(In reply to comment #2) > https://qa.mandriva.com/show_bug.cgi?id=43155 seems to indicate possible issues > with interaction with p4_clockmod. I tried adding p4_clockmod to > /etc/modprobe.d/blacklist, but it still gets loaded on boot. No idea what. Find where it is in /lib/modules/<kernel-version>/ and rename it or delete it...
Turns out it's in cpufreq: /lib/modules/2.6.29.1-30.fc10.i686/kernel/arch/x86/kernel/cpu/cpufreq/p4-clockmod.ko and cpufreq will not load without it.
Going back to 2.6.27.19-170.2.35.fc10.i686. Default: 40.9% (138.1) npviewer.bin : __mod_timer (process_timeout) 19.9% ( 67.2) firefox : futex_wait (hrtimer_wakeup) 10.5% ( 35.4) <kernel IPI> : Rescheduling interrupts 10.2% ( 34.6) firefox : __mod_timer (process_timeout) 3.0% ( 10.0) <kernel core> : mod_timer (ehci_watchdog) Hmmm, I guess there is no governor available with this kernel....
Is there a better upstream place to file this?
I'm not sure why p4-clockmod would be required to load cpufreq.
What governor was it using before (it's in /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor) ? And what clocksource is in use? (/sys/devices/system/clocksource/clocksource0/current_clocksource)
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor userspace # cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc New kernel now: 2.6.29.1-42.fc10.i686 59.4% (743.3) <kernel core> : hrtimer_start_range_ns (tick_sched_timer) 23.0% (288.0) firefox : hrtimer_start_range_ns (hrtimer_wakeup) 8.6% (107.5) npviewer.bin : hrtimer_start_range_ns (hrtimer_wakeup) 3.6% ( 45.4) <interrupt> : ata_piix, eth0 0.8% ( 10.0) mozplugger-help : hrtimer_start_range_ns (hrtimer_wakeup) 0.8% ( 10.0) <kernel core> : mod_timer (ehci_watchdog) It also seems like I'm using more power (106W vs 96W) now with this kernel. Ondemand: 81.8% (1492.8) <kernel core> : hrtimer_start_range_ns (tick_sched_timer) 8.0% (145.7) firefox : hrtimer_start_range_ns (hrtimer_wakeup) 5.8% (105.3) npviewer.bin : hrtimer_start_range_ns (hrtimer_wakeup) 0.9% ( 16.5) <interrupt> : ata_piix, eth0 0.5% ( 10.0) <kernel core> : mod_timer (ehci_watchdog) Response is noticeably better now with ondemand, though still a bit sluggish.
You shouldn't use any governor with p4-clockmod - the only sensible choice there is to use performance. Ignore powertop's suggestions in this respect.
Should p4-clockmod be loaded? I can't seem to prevent it from being loaded. Or is it just that if p4-clockmod is loaded, then it means that you shouldn't use the ondemand governor because your CPU won't benefit from it? I'll post a comment on the powertop discussion list about not suggesting the ondemand governor in these cases if so.
p4-clockmod may be used for certain thermal issues, so it's loaded automatically. Am I right in thinking that you don't see this issue with the default settings, just if you set the CPU governor by hand?
Correct. I saw the powertop suggestion, tried it and saw the poor performance. google turned up some posts suggesting the use of ondemand without p4-clockmod loaded, which prompted that line of questioning.
Ok, I'm reassigning this to powertop on the grounds that the default system configuration works and p4-clockmod isn't expected to handle ondemand.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. 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 '10'. 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 10'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 10 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Created attachment 468407 [details] Proposed patch
powertop-1.13-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/powertop-1.13-2.fc14
powertop-1.13-2.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update powertop'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/powertop-1.13-2.fc14
powertop-1.13-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.