Linux power management: are you doing it right?

Linux power management: are you doing it
right?
Chris Simmonds
Embedded World 2018
Linux power management: are you doing it right? 1 Copyright © 2011-2018, 2net Ltd

License
These slides are available under a Creative Commons Attribution-ShareAlike 3.0 license. You can read the full
text of the license here
http://creativecommons.org/licenses/by-sa/3.0/legalcode
You are free to
• copy, distribute, display, and perform the work
• make derivative works
• make commercial use of the work
Under the following conditions
• Attribution: you must give the original author credit
• Share Alike: if you alter, transform, or build upon this work, you may distribute the resulting work only
under a license identical to this one (i.e. include this page exactly as it is)
• For any reuse or distribution, you must make clear to others the license terms of this work

About Chris Simmonds
• Consultant and trainer
• Author of Mastering Embedded Linux Programming
• Working with embedded Linux since 1999
• Android since 2009
• Speaker at many conferences and workshops
"Looking after the Inner Penguin" blog at http://2net.co.uk/
https://uk.linkedin.com/in/chrisdsimmonds/
https://google.com/+chrissimmonds

Overview
• Reducing power usage is important, especially for battery-powered
devices
• In this talk I will introduce
• The rules of power management
• The major Linux systems that implement power management
• Some practical measures you can take

The rules of power management
1. Don’t rush if you don’t have to
2. Take a break when things are quiet
3. Turn things off when they are not in use
4. Have a snooze when you expect things to be quite for a while

Rule 1: Don’t rush
• Reducing CPU frequency saves power?
• P = CfV2
• Reducing voltage, not frequency, saves power
• But, lowering frequency allows for lowering the voltage, and therefore
saves power
• The tuple of frequency and voltage is called an Operating Performance
Point (OPP)
• The ability to change OPP at run-time is called Dynamic Voltage and
Frequency Scaling (DVFS)

OPP deﬁnitions in device tree
Example from am33xx.dtsi
cpu0_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
syscon = <&scm_conf>;
opp50@300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <950000 931000 969000>;
opp-supported-hw = <0x06 0x0010>;
opp-suspend;
};
opp100@600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x06 0x0040>;
};
[...]
};

CPUFreq
• In Linux, selecting the best OPP is done by the CPUFreq driver
• Enable with kernel option CONFIG_CPU_FREQ=y
• Part of the Linux support for each SoC
• Control is per CPU, via directory /sys/devices/system/cpu/cpuN/cpufreq
• List of possible frequencies (corresponding to OPPs):
# cd /sys/devices/system/cpu/cpu0/cpufreq
# cat scaling_available_frequencies
300000 600000 720000 800000

CPUFreq Governors
• The policy for changing the OPP is controlled by a governor
• There are a small number of governors coded into Linux:
# cd /sys/devices/system/cpu/cpu0/cpufreq
# cat scaling_available_governors
conservative ondemand userspace powersave performance

Governors
• powersave: Always selects the lowest frequency
• performance: Always selects the highest frequency
• ondemand: Changes frequency based on the CPU utilization. If the
CPU is idle less than 20% of the time, it sets the frequency to the
maximum; if it is idle more than 30% of the time, it decrements the
frequency by 5%
• conservative: As ondemand , but switches to higher frequencies in
5% steps rather than going immediately to the maximum
• userspace: Frequency is set by a user space program

Example of the potential power saving
• BeagleBone Black running a constant load
• No governor: using ﬁxed frequencies
OPP Freq MHz CPU use, % Power, mW
OPP50 300 94 320
OPP100 600 48 345
OPP120 720 40 370
Turbo 800 34 370
Nitro 1000 28 370
15% saving by running the job at 300 MHz instead of 1 GHz

Rule 2: take a break
• When the CPU has nothing to do, it enters an idle state
• Usually, there are several idle states to choose from
• Sometimes known as C-states
• Deeper idle states take longer to return to full operation
• Example: the CPU L1 cache may be powered down, so it takes time to
re-load the cache when restarting

CPUIdle
• In Linux, the transition between idle states is controlled by the CPUIdle
driver
• Enable with kernel option CONFIG_CPU_IDLE
• Information about idle state C for CPU N is in
/sys/devices/system/cpu/cpuN/cpuidle/stateC
• For example the TI AM335x SoC has only two states
• State0: WFI (Wait For Interrupt)
• State1: C1

CPUIdle governors
• The policy for selecting idle states is controlled by the CPUIdle
governor
• Cannot be changed at run-time
• Only two options
• ladder: steps through the idle states one at a time depending on the
time spent in the last idle period. Works well with a regular timer tick
• menu: selects an idle state based on the expected idle time. Works well
with tickless systems

Tickless operation
• Linux was written assuming a constant tick, typically 100Hz
• On an idle system, this is a waste of CPU power; stops the CU
entering deeper sleep states
• For tickless operation, conﬁgure your kernel with CONFIG_NO_HZ_IDLE=y
(on older kernels, CONFIG_NO_HZ=y)
• Schedules timer interrupts for the next event, skipping any intermediate
ticks
• Potential power saving on a device that is mostly idle: up to 70%

Rule 3: turn things off
• Managing the power usage of peripherals is also important
• In Linux, the runtime power management (pm runtime) tracks the
state of pm-aware device drivers
• Each device driver can register callback functions such as
runtime_suspend and runtime_resume
• Kernel conﬁguration option CONFIG_PM

Controlling pm runtime
• PM runtime is exposed via directory power for each device that
supports it
• Files in that directory include:
• control: "auto": kernel will select state; "on": device always on (pm
runtime disabled)
• runtime_status: current state of the device: "active", "suspended", or
"unsupported"
• autosuspend_delay_ms: minimum time before suspending device

Runtime PM
• For example, the MMC controller on TI AM335x
# cd /sys/devices/platform/ocp/481d8000.mmc/mmc_host/mmc1/mmc1:0001/power
# grep "" *
async:disabled
autosuspend_delay_ms:3000
control:auto
runtime_active_kids:0
runtime_active_time:164440
runtime_enabled:enabled
runtime_status:suspended
runtime_suspended_time:139270
runtime_usage:0
• Note that autosuspend_delay_ms is 3 seconds
• That runtime_status is "suspended"

Rule 4: Have a snooze
• The techniques so far will optimize power usage of a running system
• Largest power saving comes from entering a system sleep mode
• Example: when closing the lid of a laptop
• Example: Android device suspending after activity timeout (default 60
seconds)

Power states
Sleep state S-state Description
freeze Stops (freezes) all activity in user space
standby S1 Powers down all CPUs except the boot CPU
mem S3 Powers down the system, puts RAM into self-refresh
disk S4 Saves memory to disk, followed by complete power down
Linux sleep states, together with equivalent ACPI S-state
• mem (suspend to RAM) typically consumes a few milliamps
(dependent on board design and BSP)
• disk (suspend to disk) typically consumes no power at all

Controlling power state
• In Linux, macro power management is via by the power management
subsystem
• Enable with kernel option CONFIG_PM
• You can view the sleep states implemented in BSP via /sys/power/state
# cat /sys/power/state
freeze standby mem disk
• mem is the one most often used in embedded systems
• disk (aka hibernation) is usually too slow and takes too much storage
when using ﬂash memory

Changing power state
• Simply, write the desired state to /sys/power/state
• For example, to enter suspend mode:
# echo mem > /sys/power/state
[ 1646.158274] PM: Syncing filesystems ...done.
[ 1646.178387] Freezing user space processes ...(elapsed 0.001 seconds)
done.
[ 1646.188098] Freezing remaining freezable tasks ...
(elapsed 0.001 seconds) done.
[ 1646.197017] Suspending console(s) (use
no_console_suspend to debug)
[ 1646.338657] PM: suspend of devices complete
after 134.322 msecs
[ 1646.343428] PM: late suspend of devices

Waking up
• CPU is woken by interrupt or other input
• Wakeup sources need to be powered while the main CPU is powered
down
• Wakeup sources may include
• Real-time clock (RTC)
• Certain GPIO pins
• UART
• Usually managed by a dedicated Power Management chip, PMIC

Wakeup sources
• Devices that can act as wakeup sources have
/sys/devices/.../power/wakeup set to "enabled"
• For example, GPIOs 0 to 7 on AM335x
# cat /sys/devices/platform/gpio_keys/power/wakeup
enabled
• Hence, pressing the power button wakes the device

Conclusion
• A well conﬁgured Linux device will save power
• Linux features considered here:
• CPUFreq: selects OPP depending on load
• CPUIdle: selects idle state based on predicted load
• Tickless: eliminates unnecessary timer interrupts
• Runtime power management: powers off unused peripherals
• Suspend to RAM: puts system in minimum power usage state

Questions?
Further reading: Chapter 11 of Mastering Embedded Linux Programming
Contact:
Web: www.2net.co.uk
Email: training@2net.co.uk
LinkedIn: https://uk.linkedin.com/in/chrisdsimmonds

Linux power management: are you doing it right?

More Related Content

What's hot (20)

Similar to Linux power management: are you doing it right? (20)

More from Chris Simmonds (20)

Recently uploaded (20)

Linux power management: are you doing it right?