For most embedded systems, particularly for consumer electronics like smartphone systems, in order to extend battery life and reduce charging time per day, power consumption should be controlled.
The power issue becomes more and more critical in smartphone systems because of the conflicts of higher function requirements and performance requirements, but limited battery capacity and a smaller hardware model.
The whole power-cost optimization topic is very systematic; it is related to hardware system design and the power management policies of the software system.
The hardware elements that need to be considered in the power-cost balance are CPU, memory and external devices, and system components, such as clock, power domain, and regulator.
The corresponding software management topics include CPU idle, CPU frequency, CPU hotplug, memory hotplug, memory frequency, bus frequency, runtime power management, clock management, power domain management, and system suspend.
It's not possible to explain all of them, but we'll introduce an applet that can give us power optimization suggestions, and can measure top power-cost events.
PowerTOP (https://01.org/powertop/) is designed to measure, explain, and minimize a computer's electrical power consumption; it not only works on x86 systems, but also supports ARM, AMD, and other kinds of architectures.
Enable basic Linux kernel support for PowerTOP:
To make PowerTOP work, the kernel must be configured with
CONFIG_TIMER_STATS=y.Kernel hacking ---> [*] Collect kernel timers statistics
Then compile and flush it to the target platform.
Configure PowerTOP in BusyBox:
BusyBox already has a tiny version of PowerTOP integrated; to use it, make sure it is enabled in the BusyBox configuration.
Process Utilities ---> [*] powertop
Using PowerTOP:
Let's run it as follows on the Android emulator:
$ adb shell shell@android:/ # powertop C-state information is not available Wakeups-from-idle in 10 seconds: 308 Top causes for wakeups: 38.1% ( 115) <interrupt> : Goldfish Timer Tick 17.9% ( 54) <kernel core> : hrtimer_start (tick_sched_timer) 14.9% ( 45) yaffs-bg-1 : add_timer (yaffs_background_waker) 12.3% ( 37) <kernel core> : hrtimer_start_range_ns (tick_sched_timer) 4.6% ( 14) <interrupt> : goldfish_pipe 3.6% ( 11) m.android.phone : hrtimer_start_range_ns (hrtimer_wakeup) 3.3% ( 10) <kernel core> : dev_watchdog (dev_watchdog) 3.0% ( 9) VSyncThread : hrtimer_start_range_ns (hrtimer_wakeup) 0.7% ( 2) <kernel core> : bdi_arm_supers_timer (sync_supers_timer_fn) 0.3% ( 1) <interrupt> : goldfish_fb 0.3% ( 1) FinalizerWatchd : hrtimer_start_range_ns (hrtimer_wakeup) 0.3% ( 1) er.ServerThread : hrtimer_start (devalarm_hrthandler)
We can see that the
Goldfish Timer Tickinterrupt wakes up the system that is idle for 115 times in 10 seconds. In a real Android device, it may differ from the mentioned outputs.If the events wake up the system that is idle too frequently, the power cost will be increased remarkably. So, the major causes for wakeups should be attended to and their working frequency should be decreased by tuning the respective kernel drivers.
For example, to reduce the interrupt of
Goldfish Timer Tick, theHZconfiguration of the Linux kernel should be decreased to reduce the ticks per second; for example, replacingCONFIG_HZ=1000withCONFIG_HZ=100may reduce 90 percent system timer interrupts in a second.
The ideal working status that is power cost friendly is putting the system into an idle state as far as possible or eventually shutting down all of the devices.
To reduce the power cost of a single device, we should put it into a deeper idle state with less voltage and working frequency (if supported) or power it off eventually if nobody uses it. On the contrary, if some events wake up the device from the idle state to the active state frequently, the device will cost more power; such events are often used as the most important indicators to reduce power cost.
We learned about the switching of a system or device state from idle to active and introduced the PowerTOP tool, which can monitor this switching.
In Android, the command dumpsys alarm can track the alarms that wake up the system from a suspend state (a deeper idle state).
But even if we fix all potential wakeup causes, the power cost may still need to be optimized in other aspects. This means even in an idle state, there will be power leaking, which should be fixed up by the GPIO and register settings based on the datasheets of specific chips.
In an active state, power and performance should be balanced carefully with DVFS, clock gating, regulator gating, or power QOS policies.
The system or device should enter into an idle state from an active state timely if there is no activity.
In Android, if there is an activity request, wake_lock is held. The system will not switch from an active state to an idle state until the lock is released. To reduce power cost, the lock-holding time should be as short as possible. To track the holding of such wake locks, the /proc/wakelocks or /sys/kernel/debug/wakeup_sources interface helps, and the dumpsys power command may give more related information.