Linux System Suspend: Compare s2idle, Standby, and Deep Sleep

The word “suspend” can refer to different Linux system sleep states. s2idle is a software-coordinated low-power state in which devices are suspended and CPUs can enter idle states, while the platform remains able to wake through in-band interrupts. standby and deep correspond by convention to progressively deeper hardware-assisted states when supported. Hibernation is suspend-to-disk and has a separate image/resume path. Treating all four as the same feature makes battery and wakeup diagnostics needlessly confusing.

Available states depend on kernel configuration and platform capabilities. The default suspend variant can be deep or s2idle, and the kernel command line can influence that default. Check the target system before comparing behavior.

Inspect supported variants first

The kernel exposes system sleep states in /sys/power/state and, when suspend variants are supported, /sys/power/mem_sleep. The selected variant appears in square brackets in the latter file. Do not assume mem always means suspend-to-RAM; it refers to whichever supported variant is currently associated with that entry.

printf 'states: '; cat /sys/power/state
if [ -r /sys/power/mem_sleep ]; then
    printf 'mem variants: '; cat /sys/power/mem_sleep
fi
cat /proc/cmdline

These commands are read-only. Changing mem_sleep and writing a suspend state initiates a real system sleep. Do not test it remotely or unattended without a local recovery path and unsaved work checkpointed.

What s2idle does and does not mean

Suspend-to-idle freezes user space, suspends timekeeping, and places I/O devices into low-power states. CPUs can spend time in their deepest idle states while the system is suspended. Wakeup uses in-band interrupts, so devices that can generate interrupts in the working state may be configured as wake sources. The state can be available on platforms without traditional suspend-to-RAM support or as an option with lower resume latency.

Because s2idle depends on devices and interrupts remaining quiet, a device that generates frequent wake events can prevent deep idle residency and drain energy. A system can report that it entered s2idle yet use more power than expected. Trace wakeup sources and device behavior rather than concluding that the state is unsupported.

Standby and deep suspend

Standby, often called shallow suspend, retains more system-core power and takes non-boot CPUs offline during the transition. Deep suspend, by convention, maps to suspend-to-RAM where supported and can provide greater energy savings with longer resume latency. Hardware and firmware must support these modes; Linux cannot manufacture platform capability by changing a sysfs value.

The device suspend/resume callback path differs in meaningful ways between s2idle and deeper states. A device may work in s2idle but fail after a deeper transition because the platform power domain, firmware, or driver resume path is different. Conversely, a firmware wake source may function only in the deeper state. Test the exact variant used in production with the full device set attached.

The choice can also depend on the product’s latency and connectivity requirements. A laptop that must receive certain network or input wakeups may need a different state than a server that prioritizes minimum power. If the firmware only exposes a subset of sleep states, the kernel may select a lighter fallback. Record the supported list and the active bracketed variant after every relevant firmware or kernel change; do not infer it from the marketing name of a sleep option in the desktop UI.

Timekeeping and clock behavior change during system sleep. A wall-clock value after resume may have advanced even when the system did not execute userspace code during the interval. Use the documented clock semantics for measuring sleep duration, and do not use a process CPU timer or a monotonic clock variant that excludes suspend when the requirement is elapsed wall duration including sleep. Validate timer behavior with the actual clock API used by the application.

Wakeup sources and tracing

Use the kernel’s wakeup-source accounting and suspend trace facilities to identify which device or event ended a sleep cycle. Compare the expected wake source with the actual event. A system may wake from a periodic network packet, USB input, timer, or device interrupt before the requested duration expires.

The /sys/power/wakeup_count interface participates in a race-free userspace suspend protocol for appropriate tools. Prefer the distribution’s power-management service rather than creating a custom suspend sequence. A userspace script that checks wakeup state and then sleeps without the documented protocol can race a wakeup event.

Some wake-capable devices expose a wakeup policy attribute, but changing it can disable expected user input or remote-management behavior. Before modifying it, identify which device is the intended wake source and how firmware maps that source. A USB device may sit behind a hub or controller, so the visible peripheral name may not be the interface that actually signals wake. Use supported kernel tracing and platform documentation to map the chain.

On systems that wake immediately after entering suspend, distinguish a wake event that was pending before the request from one generated after the platform reached the target state. A stale event, repeated interrupt, or misconfigured wake source can create an apparently failed suspend. Capture event timestamps and the PM core’s transition log around a controlled test rather than treating the final state string as sufficient evidence.

For failures, enable the supported PM debugging tools and inspect kernel logs for the last device transition. pm_test can isolate parts of the suspend/resume sequence without entering the full hardware state. pm_trace can record fingerprints in RTC memory for certain failures, but the kernel documentation warns that enabling it overwrites actual RTC information. Use it only when its side effects are acceptable and capture the original time state first.

Power, latency, and test methodology

Compare variants using energy over a realistic sleep window, not only immediate idle power. Measure time to suspend, time to resume, battery loss, wake reliability, and whether the intended peripherals remain usable. Repeat tests because a race or device-specific failure may appear only after several cycles.

Control the test conditions: same firmware, kernel, peripherals, network state, battery level, and workload. Test with lid-close events, timers, USB devices, network connectivity, and external displays as relevant. A wake-on-LAN requirement may produce different results between s2idle and deep sleep because the device and firmware paths differ.

Measure both successful and unsuccessful transitions. Record the requested state, actual selected variant, suspend entry and exit timestamps, wake reason, battery delta, and post-resume device health. Repeat enough cycles to catch intermittent resume failures and include a test after device hotplug or docking if those events are normal in production. If only one variant fails, compare the device callbacks and firmware paths before choosing the workaround as a permanent default.

If a system fails to resume, preserve the kernel log and test one variable at a time: sleep variant, peripheral, driver, or firmware. Restore the normal variant after testing. Do not disable a device or change a global kernel parameter permanently just because one configuration passed once.

Operational acceptance

Document which sleep variants are supported, which one userspace selects, expected wake sources, power and resume targets, known peripheral restrictions, and the tested firmware/kernel combinations. Ensure the deployed power manager owns variant selection and can apply updates intentionally. Validate cold boot and hibernation separately from system suspend.

Linux system suspend is a family of states with different power, latency, and wakeup behavior. Inspect the supported variants, identify the active one, trace wake events, and test platform callbacks end to end. A correct label in sysfs is only the beginning of a reliable suspend path.

Related:

Sources: