# powerTOP - pruning extra timer interrupts

## .yankee

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.

```

     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.

----------

## .yankee

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?

----------

## dmpogo

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

----------

## dmpogo

 *.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.

----------

## .yankee

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...  :Sad: 

 *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?

----------

## dmpogo

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.

----------

