| View previous topic :: View next topic |
| Author |
Message |
.yankee
Apprentice
Joined: 24 Feb 2008
Posts: 194
Location: Polska
|
 Posted: Mon Dec 08, 2008 9:35 pm Post subject: powerTOP - pruning extra timer interrupts |
 |
|
I recently installed sys-power/powertop to see if I can lower the power consumption of my laptop. It surprised me, how much could be easily done. After switching to a tickless system and enabling HPET, the time my cpu spends in a C3 state increased about 10 times!
But still, I get some issues. Below is an example powertop output.
| Code: |
PowerTOP version 1.9 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies)
C0 (cpu running) ( 7,6%) 1200 Mhz 0,0%
C1 0,0ms ( 0,0%) 800 Mhz 100,0%
C2 5,4ms (40,2%)
C3 2,0ms (52,2%)
Wakeups-from-idle per second : 335,6 interval: 15,0s
Power usage (5 minute ACPI estimate) : 14,2 W (1,2 hours left)
Top causes for wakeups:
60,2% (252,7) <interrupt> : PS/2 keyboard/mouse/touchpad
15,7% ( 66,0) <interrupt> : extra timer interrupt
12,5% ( 52,4) <interrupt> : Intel 82801CA-ICH3, wifi0
4,9% ( 20,7) X : schedule_timeout (process_timeout)
4,1% ( 17,1) X : do_setitimer (it_real_fn)
1,3% ( 5,5) opera : schedule_timeout (process_timeout)
0,2% ( 1,0) <kernel core> : ath_detach (ath_intr)
0,1% ( 0,5) <kernel core> : queue_delayed_work_on (delayed_work_timer_fn)
0,1% ( 0,5) gpm : do_nanosleep (hrtimer_wakeup)
0,1% ( 0,5) slim : do_setitimer (it_real_fn)
0,1% ( 0,5) urxvt : schedule_timeout (process_timeout)
|
As one can see, there still occur too many extra timer interrupts. I wonder if it has something to do with how I enabled HPET. And this leads to an important question:
Do I need rtc at all, if HPET is on?
I compiled it as a module now - and it gets loaded at start-up, because /etc/init.d/clock wants it -can that be changed? If I unload rtc afterwards, there seem to be far less interrupts (the above powertop output was taken without rtc loaded).
As for the keyboard/mouse interrupts - I am using a synaptics touchpad - maybe there could be some way to decrease the amount of interrupts it produces?
Any help appreciated. |
|
| Back to top |
|
 |
.yankee
Apprentice
Joined: 24 Feb 2008
Posts: 194
Location: Polska
|
| Posted: Sun Dec 14, 2008 9:20 pm Post subject: |
|
|
Ok. I learned so far, that the large amount of mouse/touchpad interrupts is rather inevitable. If I only use keyboard, this interrupt cause gets far less frequent.
Also, at least 20 int/sec are due to having an animated cursor (these are included at positions X : schedule_timeout (process_timeout) and X : do_setitimer (it_real_fn)).
I'm still concerned about few positions there though.
One that I'm afraid can't be lowered without a better driver is wifi0 interrupt. With madwifi-hal, when an interface is up, it takes at least 60 int/sec.
Another - and this, I hope to fight with, is extra timer interrupt. This is more tricky and in consequence, more annoying. It usually grows when the system is in use, especially under X. It usually gets lower after a time of lowered activity, but - sadly - not always. Sometimes it just stays at some level and I've not yet found a way to get rid of that.
Any thoughts? |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3468
Location: Canada
|
| Posted: Sun Dec 14, 2008 10:02 pm Post subject: |
|
|
Keyboard/synaptics interrupts usually do not contribute much when you are not typing/browsing
Let powertop sit for until next refresh or two without touching your keyboard and you'll see they disappear.
Your powertop output definitely did not catch the CPU in a quiet moment.
extra timer interrupt I did inverstigate on the web, and come to the conclusion that they are inevitable right now.
However, even with them my time in C3 state usually goes up to 30-50ms if I am not typing.
For me the common culprits that bring the count down are firefox, which sometimes generates massive interrupts even sitting idle opened on innocent looking page, and uhci_hcd. Next in line are iwlagn, ehci_hcd.
Also, you may find that some panel applets are quite bad in this regards, polling all the time and waking CPU |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3468
Location: Canada
|
| Posted: Sun Dec 14, 2008 10:16 pm Post subject: |
|
|
| .yankee wrote: | Ok. I learned so far, that the large amount of mouse/touchpad interrupts is rather inevitable. If I only use keyboard, this interrupt cause gets far less frequent.
Also, at least 20 int/sec are due to having an animated cursor (these are included at positions X : schedule_timeout (process_timeout) and X : do_setitimer (it_real_fn)).
Any thoughts? |
And of course you want your touch pad to be responsive. When you slide your finger you probably easliy change
your position at a rate of 100 pixels/per second, i.e pixel per 0.01 sec if not faster So you would think at least 1 interrupt per milisecond
to get things smoothly has to be there. |
|
| Back to top |
|
|
.yankee
Apprentice
Joined: 24 Feb 2008
Posts: 194
Location: Polska
|
| Posted: Sun Dec 14, 2008 11:42 pm Post subject: |
|
|
Thanks for responding, dmpogo.
| dmpogo wrote: | Keyboard/synaptics interrupts usually do not contribute much when you are not typing/browsing
Let powertop sit for until next refresh or two without touching your keyboard and you'll see they disappear.
Your powertop output definitely did not catch the CPU in a quiet moment. |
Yes, I learned that soon after posting the first post here. Aftwr that, I managed to bring my system to a state, when it would not go far above 10 int/s, staying in C3 around 90% of time. But this required no wifi up, no graphical browser (though I haven't yet tested with dillo - hmm, that might be interesting...) and a lighter wm (like fluxbox -instead of compiz+xfce).
| dmpogo wrote: |
extra timer interrupt I did inverstigate on the web, and come to the conclusion that they are inevitable right now.
|
This make me a saaad Panda... 
| dmpogo wrote: |
For me the common culprits that bring the count down are firefox, which sometimes generates massive interrupts even sitting idle opened on innocent looking page, and uhci_hcd. Next in line are iwlagn, ehci_hcd.
|
As to *hci_hcd - have you, by any chance checked if any of those share an irq with the graphics card on your system? Because in my case, they are - and because of that, I rather blamed my radeon for the interrupts. Stopping hald an even udev did not help here, whereas switching from X to console made the line with radeon (and *hci_hcd) disappear.
| dmpogo wrote: |
Also, you may find that some panel applets are quite bad in this regards, polling all the time and waking CPU |
Yes, my whole cairo-dock takes about 5 int/s (at least for scheduling) - anyway, I rather switch to fluxbox or evilwm when on batteries.
How about rtc being in use together with HPET - have you some knowledge/experiences in that matter? I mean, is the latter strictly necessary for the clock service to do its job? |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3468
Location: Canada
|
| Posted: Mon Dec 15, 2008 4:50 am Post subject: |
|
|
I need to have an access to my laptop to answer your questions, which I will in a couple of days.
My understanding is that rtc is a totally different beast than hpet - rtc is a real calendar clock that 'date' shows, plus an interface to hardware clock (on the motherboard, battery powered). Alternative to hpet is tsc. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
