maemo.org - Talk - View Single Post - Timer programming, battery consumption

shadowjk	2010-07-28 , 18:58
Posts: 1,258 \| Thanked: 672 times \| Joined on Mar 2009	#7

Originally Posted by Joorin

This makes no sense. With 150+ processes running on your device, you will have some process running in the CPU at almost all time.

The kernel doesn't stop, hence the CPU can't halt. Device drivers rely on the continuous flow of timing ticks in the kernel.

Code:

The tickless kernel feature (CONFIG_NO_HZ) enables 'on-demand' timer 
interrupts: if there is no timer to be expired for say 1.5 seconds when 
the system goes idle, then the system will stay totally idle for 1.5 
seconds. This should bring cooler CPUs and power savings: on our (x86) 
testboxes we have measured the effective IRQ rate to go from HZ to 1-2 
timer interrupts per second.

http://http://kerneltrap.org/node/6750

The kernel isn't a constantly running process. Kernel code only runs if there's something that jumps into kernel, like a hardware interrupt or a software interrupt (syscall).

You can for example use powertop to check this out yourself:

Code:

C#      | Ratio  | Avg/dura | Frequency | Ratio
--------+--------+----------+-----------+--------+
     C0 |  10.0% |          |   600 MHz |   9.5% |
     C1 |   0.2% |    0.3ms |   550 MHz |   0.0% |
     C2 |  12.1% |    2.5ms |   500 MHz |  11.7% |
     C3 |  26.6% |  101.2ms |   250 MHz |  78.8% |
     C4 |  51.0% |  528.4ms |

C0 is the only state where the CPU is actually running. C4 is deepest sleep state, with even voltage to the CPU cut off. It takes the longest time to reach and exit C4, so it's only entered if it's a long time until next wakeup.

Here you can see that during the 30second sample interval, when my N900 was in my pocket, running a script (5 second timer) and xchat (woken up by chat traffic only), my N900's CPU was completely off 51% of the time.
The average time in deep sleep was half a second at a time.
When my N900's CPU was on, 10% of the time, it spent 78.8% at 250MHz.

We also get a list of IRQs, and list of processes that caused wakeups. In my case the top was kernel, mmc, wireless.

Power domain shows statistics about the individual parts of the SOC:

Code:

Power domain activity breakdown
Domain  | % of time spent in states
--------+---------+---------+---------+---------+----------
usbhost |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)
    sgx |OFF:  96%|RET:   0%|INA:   0%| ON:   3%| now:(OFF)
    per |OFF:  75%|RET:  13%|INA:   0%| ON:  10%| now:(ON)
    dss |OFF:  92%|RET:   0%|INA:   0%| ON:   7%| now:(ON)
    cam |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)
   core |OFF:  50%|RET:  24%|INA:   3%| ON:  21%| now:(ON)
   neon |OFF:  50%|RET:  26%|INA:  11%| ON:  10%| now:(ON)
    mpu |OFF:  50%|RET:  26%|INA:  11%| ON:  10%| now:(ON)
   iva2 |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

sgx: 3D accelerator
per: peripherals.. mmc and so on
dss: display subsystem. framebuffer and signal generator for the lcd
cam: camera
core: CPU Core
neon: The neon unit of the CPU
mpu: memory protection unit
iva2: video decode acceleration unit

OFF: Completely off
RET: powersaving mode
INA: On, but Inactive

As a sidenote, both intel and the QT folks are working on synchronizing timers in MeeGo. That is, the app can request a wakeup with specified precision (or lack thereof). Say you want your app to wake up every 10 second, but you don't care that much about exactly 10 second. So you can ask "10 seconds, give or take a few", and the kernel or qt can look for another app that has a similar requirements, and slowly move their timers closer together until they fire at the same time, effectively coalescing the wakeups of two apps into becoming a single wakeup.

It's much more efficient to do a alot of work at highest CPU speed, so the CPU can quickly go back to sleep, and sleep for a long time.

Quote & Reply |

The Following 3 Users Say Thank You to shadowjk For This Useful Post:
fnordianslip, harriva, qwerty12