Linux suspend types: disk, mem (ACPI S3), (standby but nothing really supports it), freeze. Suspend-to-mem turns everything off except what is needed to turn on again. Low power idle is an additional state (not ACPI S3) is a state that doesn’t turn everything off and resumes a lot faster. freeze is the lowest power state that allows fast resume; this can be just an active idle state if low power idle doesn’t exist.
Low power idle is treated as a system suspend by Linux, even though not all devices are turned off.
Handheld devices wake up to do almost nothing (getting some wifi/data packet that needs little processing). Therefore, the power spent on suspend/resume itself becomes dominant compared to the compute time. Shortening the suspend/resume time therefore reduces energy consumption.
To go faster: eliminate waiting, do things in parallel, work asynchronously, or avoid work entirely.
To make things go faster, you first need measurements. Stopwatch and camera are good tools to start with, but doesn’t tell you what exactly happened. initcall_debug gives dmesg measurements of resume functions. analyze_suspend.py (https://github.com/01org/suspendresume), run as root, uses ftrace. It gives graphical display of the suspend and resume devices in an HTML page. It shows only the kernel resume, not userspace. Firmware resume (i.e. what BIOS/UEFI adds) is not included in the graph but it is reported (it’s not always reliable).
Currently in system suspend, there is no tracking of dependencies between devices. Instead, a device just declares itself synchronous, and all synchronous devices are serialized.
With -f option, you also get a call trace in the HMTL with timing info.
By turning a bunch of things of, you can get down to 60ms suspend-resume cycle (normally it’s 1.6s resume time…).
To improve suspend, we should make sure that devices are run-time suspended when you go to system suspend, they stay run-time suspended and are not resumed. Wifi association could also be improved.