admin-guide/pm/sleep-states.rst

1 .. SPDX-License-Identifier: GPL-2.0
13 Sleep states are global low-power states of the entire system in which user
14 space code cannot be executed and the overall system activity is significantly
21 Depending on its configuration and the capabilities of the platform it runs on,
22 the Linux kernel can support up to four system sleep states, including
23 hibernation and up to three variants of system suspend.  The sleep states that
24 can be supported by the kernel are listed below.
28 Suspend-to-Idle
29 ---------------
31 This is a generic, pure software, light-weight variant of system suspend (also
33 runtime idle by freezing user space, suspending the timekeeping and putting all
34 I/O devices into low-power states (possibly lower-power than available in the
35 working state), such that the processors can spend time in their deepest idle
36 states while the system is suspended.
38 The system is woken up from this state by in-band interrupts, so theoretically
39 any devices that can cause interrupts to be generated in the working state can
42 This state can be used on platforms without support for :ref:`standby <standby>`
43 or :ref:`suspend-to-RAM <s2ram>`, or it can be used in addition to any of the
45 supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration option is set.
50 -------
53 providing a relatively straightforward transition back to the working state.  No
54 operating state is lost (the system core logic retains power), so the system can
55 go back to where it left off easily enough.
57 In addition to freezing user space, suspending the timekeeping and putting all
58 I/O devices into low-power states, which is done for :ref:`suspend-to-idle
59 <s2idle>` too, nonboot CPUs are taken offline and all low-level system functions
61 allow more energy to be saved relative to :ref:`suspend-to-idle <s2idle>`, but
62 the resume latency will generally be greater than for that state.
64 The set of devices that can wake up the system from this state usually is
65 reduced relative to :ref:`suspend-to-idle <s2idle>` and it may be necessary to
66 rely on the platform for setting up the wakeup functionality as appropriate.
68 This state is supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration
69 option is set and the support for it is registered by the platform with the
70 core system suspend subsystem.  On ACPI-based systems this state is mapped to
71 the S1 system state defined by ACPI.
75 Suspend-to-RAM
76 --------------
79 energy savings as everything in the system is put into a low-power state, except
80 for memory, which should be placed into the self-refresh mode to retain its
81 contents.  All of the steps carried out when entering :ref:`standby <standby>`
83 take place depending on the platform capabilities.  In particular, on ACPI-based
84 systems the kernel passes control to the platform firmware (BIOS) as the last
86 more low-level components that are not directly controlled by the kernel.
88 The state of devices and CPUs is saved and held in memory.  All devices are
89 suspended and put into low-power states.  In many cases, all peripheral buses
90 lose power when entering S2RAM, so devices must be able to handle the transition
91 back to the "on" state.
93 On ACPI-based systems S2RAM requires some minimal boot-strapping code in the
94 platform firmware to resume the system from it.  This may be the case on other
97 The set of devices that can wake up the system from S2RAM usually is reduced
98 relative to :ref:`suspend-to-idle <s2idle>` and :ref:`standby <standby>` and it
99 may be necessary to rely on the platform for setting up the wakeup functionality
102 S2RAM is supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration option
103 is set and the support for it is registered by the platform with the core system
104 suspend subsystem.  On ACPI-based systems it is mapped to the S3 system state
110 -----------
112 This state (also referred to as Suspend-to-Disk or STD) offers the greatest
113 energy savings and can be used even in the absence of low-level platform support
114 for system suspend.  However, it requires some low-level code for resuming the
115 system to be present for the underlying CPU architecture.
117 Hibernation is significantly different from any of the system suspend variants.
121 First, when hibernation is triggered, the kernel stops all system activity and
123 the system goes into a state in which the snapshot image can be saved, the image
124 is written out and finally the system goes into the target low-power state in
128 Once the snapshot image has been written out, the system may either enter a
129 special low-power state (like ACPI S4), or it may simply power down itself.
130 Powering down means minimum power draw and it allows this mechanism to work on
131 any system.  However, entering a special low-power state may allow additional
132 means of system wakeup to be used  (e.g. pressing a key on the keyboard or
135 After wakeup, control goes to the platform firmware that runs a boot loader
136 which boots a fresh instance of the kernel (control may also go directly to
137 the boot loader, depending on the system configuration, but anyway it causes
138 a fresh instance of the kernel to be booted).  That new instance of the kernel
139 (referred to as the ``restore kernel``) looks for a hibernation image in
141 activity in the system is stopped and the restore kernel overwrites itself with
142 the image contents and jumps into a special trampoline area in the original
143 kernel stored in the image (referred to as the ``image kernel``), which is where
144 the special architecture-specific low-level code is needed.  Finally, the
145 image kernel restores the system to the pre-hibernation state and allows user
148 Hibernation is supported if the :c:macro:`CONFIG_HIBERNATION` kernel
150 for the given CPU architecture includes the low-level code for system resume.
156 The power management subsystem provides userspace with a unified ``sysfs``
157 interface for system sleep regardless of the underlying system architecture or
158 platform.  That interface is located in the :file:`/sys/power/` directory
159 (assuming that ``sysfs`` is mounted at :file:`/sys`) and it consists of the
164 	by the kernel.  Writing one of these strings into it causes the kernel
165 	to start a transition of the system into the sleep state represented by
168 	In particular, the "disk", "freeze" and "standby" strings represent the
169 	:ref:`hibernation <hibernation>`, :ref:`suspend-to-idle <s2idle>` and
170 	:ref:`standby <standby>` sleep states, respectively.  The "mem" string
171 	is interpreted in accordance with the contents of the ``mem_sleep`` file
174 	If the kernel does not support any system sleep states, this file is
179 	suspend	variants and allows user space to select the variant to be
180 	associated with the "mem" string in the ``state`` file described above.
182 	The strings that may be present in this file are "s2idle", "shallow"
183 	and "deep".  The "s2idle" string always represents :ref:`suspend-to-idle
185 	:ref:`standby <standby>` and :ref:`suspend-to-RAM <s2ram>`,
188 	Writing one of the listed strings into this file causes the system
189 	suspend variant represented by it to be associated with the "mem" string
190 	in the ``state`` file.  The string representing the suspend variant
191 	currently associated with the "mem" string in the ``state`` file is
194 	If the kernel does not support system suspend, this file is not present.
197 	This file controls the operating mode of hibernation (Suspend-to-Disk).
198 	Specifically, it tells the kernel what to do after creating a
204 		Put the system into a special low-power state (e.g. ACPI S4) to
205 		make additional wakeup options available and possibly allow the
209 		It is only available if the platform provides a special
210 		mechanism to put the system to sleep after creating a
215 		Power off the system.
218 		Reboot the system (useful for diagnostics mostly).
221 		Hybrid system suspend.  Put the system into the suspend sleep
222 		state selected through the ``mem_sleep`` file described above.
223 		If the system is successfully woken up from that state, discard
224 		the hibernation image and continue.  Otherwise, use the image
225 		to restore the previous state of the system.
230 		Diagnostic operation.  Load the image as though the system had
231 		just woken up from hibernation and the currently running kernel
235 	Writing one of the strings listed above into this file causes the option
238 	The currently selected option is shown in square brackets, which means
239 	that the operation represented by it will be carried out after creating
240 	and saving the image when hibernation is triggered by writing ``disk``
243 	If the kernel does not support hibernation, this file is not present.
246 	This file controls the size of hibernation images.
248 	It can be written a string representing a non-negative integer that will
249 	be used as a best-effort upper limit of the image size, in bytes.  The
250 	hibernation core will do its best to ensure that the image size will not
253 	possible.  In particular, writing '0' to this file causes the size of
256 	Reading from it returns the current image size limit, which is set to
257 	around 2/5 of the available RAM size by default.
260 	This file controls the "PM trace" mechanism saving the last suspend
261 	or resume event point in the RTC memory across reboots.  It helps to
265 	If it contains "1", the fingerprint of each suspend/resume event point
266 	in turn will be stored in the RTC memory (overwriting the actual RTC
268 	after storing it and it can be used later to identify the driver that
269 	caused the crash to happen.
274 According to the above, there are two ways to make the system go into the
275 :ref:`suspend-to-idle <s2idle>` state.  The first one is to write "freeze"
276 directly to :file:`/sys/power/state`.  The second one is to write "s2idle" to
278 :file:`/sys/power/state`.  Likewise, there are two ways to make the system go
279 into the :ref:`standby <standby>` state (the strings to write to the control
281 state is supported by the platform.  However, there is only one way to make the
282 system go into the :ref:`suspend-to-RAM <s2ram>` state (write "deep" into
285 The default suspend variant (ie. the one to be used without writing anything
286 into :file:`/sys/power/mem_sleep`) is either "deep" (on the majority of systems
287 supporting :ref:`suspend-to-RAM <s2ram>`) or "s2idle", but it can be overridden
288 by the value of the ``mem_sleep_default`` parameter in the kernel command line.
289 On some systems with ACPI, depending on the information in the ACPI tables, the
290 default may be "s2idle" even if :ref:`suspend-to-RAM <s2ram>` is supported in