110 lines
5.0 KiB
Plaintext
110 lines
5.0 KiB
Plaintext
System Power Management Sleep States
|
|
|
|
(C) 2014 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
|
|
The kernel supports up to four system sleep states generically, although three
|
|
of them depend on the platform support code to implement the low-level details
|
|
for each state.
|
|
|
|
The states are represented by strings that can be read or written to the
|
|
/sys/power/state file. Those strings may be "mem", "standby", "freeze" and
|
|
"disk", where the last one always represents hibernation (Suspend-To-Disk) and
|
|
the meaning of the remaining ones depends on the relative_sleep_states command
|
|
line argument.
|
|
|
|
For relative_sleep_states=1, the strings "mem", "standby" and "freeze" label the
|
|
available non-hibernation sleep states from the deepest to the shallowest,
|
|
respectively. In that case, "mem" is always present in /sys/power/state,
|
|
because there is at least one non-hibernation sleep state in every system. If
|
|
the given system supports two non-hibernation sleep states, "standby" is present
|
|
in /sys/power/state in addition to "mem". If the system supports three
|
|
non-hibernation sleep states, "freeze" will be present in /sys/power/state in
|
|
addition to "mem" and "standby".
|
|
|
|
For relative_sleep_states=0, which is the default, the following descriptions
|
|
apply.
|
|
|
|
state: Suspend-To-Idle
|
|
ACPI state: S0
|
|
Label: "freeze"
|
|
|
|
This state is a generic, pure software, light-weight, system sleep state.
|
|
It allows more energy to be saved relative to runtime idle by freezing user
|
|
space and putting all I/O devices into low-power states (possibly
|
|
lower-power than available at run time), such that the processors can
|
|
spend more time in their idle states.
|
|
|
|
This state can be used for platforms without Power-On Suspend/Suspend-to-RAM
|
|
support, or it can be used in addition to Suspend-to-RAM (memory sleep)
|
|
to provide reduced resume latency. It is always supported.
|
|
|
|
|
|
State: Standby / Power-On Suspend
|
|
ACPI State: S1
|
|
Label: "standby"
|
|
|
|
This state, if supported, offers moderate, though real, power savings, while
|
|
providing a relatively low-latency transition back to a working system. No
|
|
operating state is lost (the CPU retains power), so the system easily starts up
|
|
again where it left off.
|
|
|
|
In addition to freezing user space and putting all I/O devices into low-power
|
|
states, which is done for Suspend-To-Idle too, nonboot CPUs are taken offline
|
|
and all low-level system functions are suspended during transitions into this
|
|
state. For this reason, it should allow more energy to be saved relative to
|
|
Suspend-To-Idle, but the resume latency will generally be greater than for that
|
|
state.
|
|
|
|
|
|
State: Suspend-to-RAM
|
|
ACPI State: S3
|
|
Label: "mem"
|
|
|
|
This state, if supported, offers significant power savings as everything in the
|
|
system is put into a low-power state, except for memory, which should be placed
|
|
into the self-refresh mode to retain its contents. All of the steps carried out
|
|
when entering Power-On Suspend are also carried out during transitions to STR.
|
|
Additional operations may take place depending on the platform capabilities. In
|
|
particular, on ACPI systems the kernel passes control to the BIOS (platform
|
|
firmware) as the last step during STR transitions and that usually results in
|
|
powering down some more low-level components that aren't directly controlled by
|
|
the kernel.
|
|
|
|
System and device state is saved and kept in memory. All devices are suspended
|
|
and put into low-power states. In many cases, all peripheral buses lose power
|
|
when entering STR, so devices must be able to handle the transition back to the
|
|
"on" state.
|
|
|
|
For at least ACPI, STR requires some minimal boot-strapping code to resume the
|
|
system from it. This may be the case on other platforms too.
|
|
|
|
|
|
State: Suspend-to-disk
|
|
ACPI State: S4
|
|
Label: "disk"
|
|
|
|
This state offers the greatest power savings, and can be used even in
|
|
the absence of low-level platform support for power management. This
|
|
state operates similarly to Suspend-to-RAM, but includes a final step
|
|
of writing memory contents to disk. On resume, this is read and memory
|
|
is restored to its pre-suspend state.
|
|
|
|
STD can be handled by the firmware or the kernel. If it is handled by
|
|
the firmware, it usually requires a dedicated partition that must be
|
|
setup via another operating system for it to use. Despite the
|
|
inconvenience, this method requires minimal work by the kernel, since
|
|
the firmware will also handle restoring memory contents on resume.
|
|
|
|
For suspend-to-disk, a mechanism called 'swsusp' (Swap Suspend) is used
|
|
to write memory contents to free swap space. swsusp has some restrictive
|
|
requirements, but should work in most cases. Some, albeit outdated,
|
|
documentation can be found in Documentation/power/swsusp.txt.
|
|
Alternatively, userspace can do most of the actual suspend to disk work,
|
|
see userland-swsusp.txt.
|
|
|
|
Once memory state is written to disk, the system may either enter a
|
|
low-power state (like ACPI S4), or it may simply power down. Powering
|
|
down offers greater savings, and allows this mechanism to work on any
|
|
system. However, entering a real low-power state allows the user to
|
|
trigger wake up events (e.g. pressing a key or opening a laptop lid).
|