요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
===================
System Sleep States
===================
:Copyright: |copy| 2017 Intel Corporation
:Author: Rafael J. Wysocki <[email protected]>
Sleep states are global low-power states of the entire system in which user
space code cannot be executed and the overall system activity is significantly
reduced.
Sleep States That Can Be Supported
==================================
Depending on its configuration and the capabilities of the platform it runs on,
the Linux kernel can support up to four system sleep states, including
hibernation and up to three variants of system suspend. The sleep states that
can be supported by the kernel are listed below.
.. _s2idle:
Suspend-to-Idle
---------------
This is a generic, pure software, light-weight variant of system suspend (also
referred to as S2I or S2Idle). It allows more energy to be saved relative to
runtime idle by freezing user space, suspending the timekeeping and putting all
I/O devices into low-power states (possibly lower-power than available in the
working state), such that the processors can spend time in their deepest idle
states while the system is suspended.
The system is woken up from this state by in-band interrupts, so theoretically
any devices that can cause interrupts to be generated in the working state can
also be set up as wakeup devices for S2Idle.
This state can be used on platforms without support for :ref:`standby <standby>`
or :ref:`suspend-to-RAM <s2ram>`, or it can be used in addition to any of the
deeper system suspend variants to provide reduced resume latency. It is always
supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration option is set.
.. _standby:
Standby
-------
This state, if supported, offers moderate, but real, energy savings, while
providing a relatively straightforward transition back to the working state. No
operating state is lost (the system core logic retains power), so the system can
go back to where it left off easily enough.
In addition to freezing user space, suspending the timekeeping and putting all
I/O devices into low-power states, which is done for :ref:`suspend-to-idle
<s2idle>` 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 :ref:`suspend-to-idle <s2idle>`, but
the resume latency will generally be greater than for that state.
The set of devices that can wake up the system from this state usually is
reduced relative to :ref:`suspend-to-idle <s2idle>` and it may be necessary to
rely on the platform for setting up the wakeup functionality as appropriate.
This state is supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration
option is set and the support for it is registered by the platform with the
core system suspend subsystem. On ACPI-based systems this state is mapped to
the S1 system state defined by ACPI.
.. _s2ram:
Suspend-to-RAM
--------------
This state (also referred to as STR or S2RAM), if supported, offers significant
energy 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 :ref:`standby <standby>`
are also carried out during transitions to S2RAM. Additional operations may
take place depending on the platform capabilities. In particular, on ACPI-based
systems the kernel passes control to the platform firmware (BIOS) as the last
step during S2RAM transitions and that usually results in powering down some
more low-level components that are not directly controlled by the kernel.
The state of devices and CPUs is saved and held in memory. All devices are
suspended and put into low-power states. In many cases, all peripheral buses
lose power when entering S2RAM, so devices must be able to handle the transition
back to the "on" state.
On ACPI-based systems S2RAM requires some minimal boot-strapping code in the
platform firmware to resume the system from it. This may be the case on other
platforms too.
The set of devices that can wake up the system from S2RAM usually is reduced
relative to :ref:`suspend-to-idle <s2idle>` and :ref:`standby <standby>` and it
may be necessary to rely on the platform for setting up the wakeup functionality
as appropriate.
S2RAM is supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration option
is set and the support for it is registered by the platform with the core system
suspend subsystem. On ACPI-based systems it is mapped to the S3 system state
defined by ACPI.
.. _hibernation:
Hibernation
-----------
This state (also referred to as Suspend-to-Disk or STD) offers the greatest
energy savings and can be used even in the absence of low-level platform support
for system suspend. However, it requires some low-level code for resuming the
system to be present for the underlying CPU architecture.
Hibernation is significantly different from any of the system suspend variants.
It takes three system state changes to put it into hibernation and two system
state changes to resume it.
First, when hibernation is triggered, the kernel stops all system activity and
creates a snapshot image of memory to be written into persistent storage. Next,
the system goes into a state in which the snapshot image can be saved, the image
is written out and finally the system goes into the target low-power state in
which power is cut from almost all of its hardware components, including memory,
except for a limited set of wakeup devices.
Once the snapshot image has been written out, the system may either enter a
special low-power state (like ACPI S4), or it may simply power down itself.
Powering down means minimum power draw and it allows this mechanism to work on
any system. However, entering a special low-power state may allow additional
means of system wakeup to be used (e.g. pressing a key on the keyboard or
opening a laptop lid).
After wakeup, control goes to the platform firmware that runs a boot loader
which boots a fresh instance of the kernel (control may also go directly to
the boot loader, depending on the system configuration, but anyway it causes
a fresh instance of the kernel to be booted). That new instance of the kernel
(referred to as the ``restore kernel``) looks for a hibernation image in
persistent storage and if one is found, it is loaded into memory. Next, all
activity in the system is stopped and the restore kernel overwrites itself with
the image contents and jumps into a special trampoline area in the original
kernel stored in the image (referred to as the ``image kernel``), which is where
the special architecture-specific low-level code is needed. Finally, the
image kernel restores the system to the pre-hibernation state and allows user
space to run again.
Hibernation is supported if the :c:macro:`CONFIG_HIBERNATION` kernel
configuration option is set. However, this option can only be set if support
for the given CPU architecture includes the low-level code for system resume.
Basic ``sysfs`` Interfaces for System Suspend and Hibernation
=============================================================
The power management subsystem provides userspace with a unified ``sysfs``
interface for system sleep regardless of the underlying system architecture or
platform. That interface is located in the :file:`/sys/power/` directory
(assuming that ``sysfs`` is mounted at :file:`/sys`) and it consists of the
following attributes (files):
``state``
This file contains a list of strings representing sleep states supported
by the kernel. Writing one of these strings into it causes the kernel
to start a transition of the system into the sleep state represented by
that string.
In particular, the "disk", "freeze" and "standby" strings represent the
:ref:`hibernation <hibernation>`, :ref:`suspend-to-idle <s2idle>` and
:ref:`standby <standby>` sleep states, respectively. The "mem" string
is interpreted in accordance with the contents of the ``mem_sleep`` file
described below.
If the kernel does not support any system sleep states, this file is
not present.
``mem_sleep``
This file contains a list of strings representing supported system
suspend variants and allows user space to select the variant to be
associated with the "mem" string in the ``state`` file described above.
The strings that may be present in this file are "s2idle", "shallow"
and "deep". The "s2idle" string always represents :ref:`suspend-to-idle
<s2idle>` and, by convention, "shallow" and "deep" represent
:ref:`standby <standby>` and :ref:`suspend-to-RAM <s2ram>`,
respectively.
Writing one of the listed strings into this file causes the system
suspend variant represented by it to be associated with the "mem" string
in the ``state`` file. The string representing the suspend variant
currently associated with the "mem" string in the ``state`` file is
shown in square brackets.
If the kernel does not support system suspend, this file is not present.
``disk``
This file controls the operating mode of hibernation (Suspend-to-Disk).
Specifically, it tells the kernel what to do after creating a
hibernation image.
Reading from it returns a list of supported options encoded as:
``platform``
Put the system into a special low-power state (e.g. ACPI S4) to
make additional wakeup options available and possibly allow the
platform firmware to take a simplified initialization path after
wakeup.
It is only available if the platform provides a special
mechanism to put the system to sleep after creating a
hibernation image (platforms with ACPI do that as a rule, for
example).
``shutdown``
Power off the system.
``reboot``
Reboot the system (useful for diagnostics mostly).
``suspend``
Hybrid system suspend. Put the system into the suspend sleep
state selected through the ``mem_sleep`` file described above.
If the system is successfully woken up from that state, discard
the hibernation image and continue. Otherwise, use the image
to restore the previous state of the system.
It is available if system suspend is supported.
``test_resume``
Diagnostic operation. Load the image as though the system had
just woken up from hibernation and the currently running kernel
instance was a restore kernel and follow up with full system
resume.
Writing one of the strings listed above into this file causes the option
represented by it to be selected.
The currently selected option is shown in square brackets, which means
that the operation represented by it will be carried out after creating
and saving the image when hibernation is triggered by writing ``disk``
to :file:`/sys/power/state`.
If the kernel does not support hibernation, this file is not present.
``image_size``
This file controls the size of hibernation images.
It can be written a string representing a non-negative integer that will
be used as a best-effort upper limit of the image size, in bytes. The
hibernation core will do its best to ensure that the image size will not
exceed that number, but if that turns out to be impossible to achieve, a
hibernation image will still be created and its size will be as small as
possible. In particular, writing '0' to this file causes the size of
hibernation images to be minimum.
Reading from it returns the current image size limit, which is set to
around 2/5 of the available RAM size by default.
``pm_trace``
This file controls the "PM trace" mechanism saving the last suspend
or resume event point in the RTC memory across reboots. It helps to
debug hard lockups or reboots due to device driver failures that occur
during system suspend or resume (which is more common) more effectively.
If it contains "1", the fingerprint of each suspend/resume event point
in turn will be stored in the RTC memory (overwriting the actual RTC
information), so it will survive a system crash if one occurs right
after storing it and it can be used later to identify the driver that
caused the crash to happen.
It contains "0" by default, which may be changed to "1" by writing a
string representing a nonzero integer into it.
According to the above, there are two ways to make the system go into the
:ref:`suspend-to-idle <s2idle>` state. The first one is to write "freeze"
directly to :file:`/sys/power/state`. The second one is to write "s2idle" to
:file:`/sys/power/mem_sleep` and then to write "mem" to
:file:`/sys/power/state`. Likewise, there are two ways to make the system go
into the :ref:`standby <standby>` state (the strings to write to the control
files in that case are "standby" or "shallow" and "mem", respectively) if that
state is supported by the platform. However, there is only one way to make the
system go into the :ref:`suspend-to-RAM <s2ram>` state (write "deep" into
:file:`/sys/power/mem_sleep` and "mem" into :file:`/sys/power/state`).
The default suspend variant (ie. the one to be used without writing anything
into :file:`/sys/power/mem_sleep`) is either "deep" (on the majority of systems
supporting :ref:`suspend-to-RAM <s2ram>`) or "s2idle", but it can be overridden
by the value of the ``mem_sleep_default`` parameter in the kernel command line.
On some systems with ACPI, depending on the information in the ACPI tables, the
default may be "s2idle" even if :ref:`suspend-to-RAM <s2ram>` is supported in
principle.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
System sleep state 개요
1-24이 문서는 `SPDX-License-Identifier: GPL-2.0`을 따르고 `<isonum.txt>`를 포함합니다. 저작권은 2017 Intel Corporation에 있으며, 작성자는 Rafael J. Wysocki `<[email protected]>`입니다.
Sleep state는 user space code를 실행할 수 없고 system 전체 활동이 크게 줄어드는 전역 low-power state입니다.
Linux kernel은 구성과 실행 중인 platform의 capability에 따라 hibernation과 최대 세 종류의 system suspend를 합쳐 최대 네 가지 system sleep state를 지원할 수 있습니다. 다음 절에서 kernel이 지원할 수 있는 상태를 설명합니다.
Suspend-to-Idle
25-46Suspend-to-Idle은 S2I 또는 S2Idle이라고도 부르는 범용 pure-software 방식의 가벼운 system suspend입니다. User space를 freeze하고 timekeeping을 suspend하며 모든 I/O device를 low-power state로 전환합니다. 이 상태는 working state에서 가능한 수준보다 더 낮을 수도 있습니다. 그 결과 system이 suspend된 동안 processor는 가장 깊은 idle state에서 시간을 보낼 수 있어 runtime idle보다 더 많은 energy를 절약합니다.
이 상태에서는 in-band interrupt로 system을 깨웁니다. 따라서 이론적으로 working state에서 interrupt를 발생시킬 수 있는 모든 device를 S2Idle wakeup device로 설정할 수 있습니다.
Suspend-to-Idle은 `Standby`나 `Suspend-to-RAM`을 지원하지 않는 platform에서 사용할 수 있습니다. 더 깊은 system suspend 방식과 함께 제공해 resume latency를 줄이는 선택지로 쓸 수도 있습니다. Kernel configuration option `CONFIG_SUSPEND`가 설정되어 있으면 항상 지원됩니다.
Standby
47-72Standby가 지원되면 비교적 간단하게 working state로 돌아오면서도 중간 정도의 실질적인 energy 절감 효과를 제공합니다. System core logic에는 power가 유지되어 operating state가 사라지지 않으므로 중단 지점으로 쉽게 돌아갈 수 있습니다.
Suspend-to-Idle과 마찬가지로 user space를 freeze하고 timekeeping을 suspend하며 모든 I/O device를 low-power state로 둡니다. 여기에 더해 nonboot CPU를 offline으로 만들고 이 상태로 전환하는 동안 모든 low-level system function을 suspend합니다. 따라서 Suspend-to-Idle보다 더 많은 energy를 절약하지만 일반적으로 resume latency는 더 큽니다.
Standby에서 system을 깨울 수 있는 device 집합은 대개 Suspend-to-Idle보다 작습니다. 적절한 wakeup 기능 설정을 platform에 맡겨야 할 수도 있습니다.
Kernel configuration option `CONFIG_SUSPEND`가 설정되어 있고 platform이 core system suspend subsystem에 지원을 등록하면 Standby를 지원합니다. ACPI 기반 system에서는 ACPI가 정의한 system state `S1`에 대응합니다.
Suspend-to-RAM
73-106Suspend-to-RAM은 STR 또는 S2RAM이라고도 합니다. 지원되는 경우 memory를 제외한 system의 모든 요소를 low-power state로 전환하므로 상당한 energy를 절약합니다. Memory는 내용을 유지하도록 self-refresh mode에 두어야 합니다. Standby에 들어갈 때 수행하는 모든 단계가 S2RAM 전환에서도 실행되며, platform capability에 따라 추가 작업이 있을 수 있습니다.
특히 ACPI 기반 system에서는 S2RAM 전환의 마지막 단계에서 kernel이 platform firmware인 BIOS에 control을 넘깁니다. 이 과정은 보통 kernel이 직접 제어하지 않는 더 많은 low-level component의 power를 끕니다.
Device와 CPU의 state는 저장되어 memory에 유지됩니다. 모든 device는 suspend되어 low-power state로 들어갑니다. 많은 경우 S2RAM 진입 시 모든 peripheral bus가 power를 잃으므로 device가 다시 `on` state로 전환되는 과정을 처리할 수 있어야 합니다.
ACPI 기반 system에서 S2RAM으로부터 resume하려면 platform firmware에 최소한의 boot-strapping code가 필요합니다. 다른 platform에서도 그럴 수 있습니다.
S2RAM에서 system을 깨울 수 있는 device 집합은 보통 Suspend-to-Idle과 Standby보다 작고, 적절한 wakeup 기능 설정을 platform에 의존해야 할 수 있습니다. `CONFIG_SUSPEND`가 설정되고 platform이 core system suspend subsystem에 지원을 등록하면 S2RAM을 지원합니다. ACPI 기반 system에서는 ACPI system state `S3`에 대응합니다.
Hibernation
107-151Hibernation은 Suspend-to-Disk 또는 STD라고도 하며 가장 큰 energy 절감 효과를 제공합니다. System suspend에 대한 low-level platform 지원이 없어도 사용할 수 있지만, 기반 CPU architecture에는 system resume를 위한 low-level code가 있어야 합니다.
Hibernation은 system suspend의 어떤 방식과도 크게 다릅니다. Hibernation에 들어가는 데 system state 변경 세 번이 필요하고 resume에는 두 번이 필요합니다.
Hibernation이 시작되면 먼저 kernel이 모든 system 활동을 멈추고 persistent storage에 기록할 memory snapshot image를 만듭니다. 이어서 snapshot image를 저장할 수 있는 state로 전환하고 image를 기록합니다. 마지막으로 제한된 wakeup device를 제외한 memory를 포함한 거의 모든 hardware component의 power를 끄는 목표 low-power state로 들어갑니다.
Snapshot image를 기록한 뒤 system은 ACPI S4 같은 특별한 low-power state에 들어가거나 단순히 스스로 power down할 수 있습니다. Power down은 power draw를 최소화하고 어떤 system에서도 이 mechanism을 사용할 수 있게 합니다. 특별한 low-power state를 사용하면 keyboard key 누르기나 laptop lid 열기 같은 추가 wakeup 방법을 제공할 수 있습니다.
Wakeup 후 control은 boot loader를 실행하는 platform firmware로 넘어갑니다. System 구성에 따라 boot loader로 직접 넘어갈 수도 있지만, 어느 경우든 새 kernel instance가 boot됩니다. `restore kernel`이라 부르는 이 새 kernel은 persistent storage에서 hibernation image를 찾고, 발견하면 memory에 load합니다.
그다음 모든 system 활동을 멈추고 restore kernel이 image 내용으로 자신을 덮어쓴 뒤, image에 저장된 원래 kernel인 `image kernel`의 특별한 trampoline 영역으로 jump합니다. 이 지점에 architecture-specific low-level code가 필요합니다. 마지막으로 image kernel이 system을 hibernation 이전 상태로 복구하고 user space를 다시 실행합니다.
Kernel configuration option `CONFIG_HIBERNATION`이 설정되어 있으면 Hibernation을 지원합니다. 다만 해당 CPU architecture의 지원 코드에 system resume용 low-level code가 포함되어 있어야 이 option을 설정할 수 있습니다.
기본 `sysfs` interface와 `state`
152-176Power management subsystem은 기반 system architecture나 platform과 관계없이 system sleep을 제어하는 통합 `sysfs` interface를 userspace에 제공합니다. `sysfs`가 `/sys`에 mount되어 있다고 가정하면 interface는 `/sys/power/` directory의 다음 attribute file로 구성됩니다.
`state` file에는 kernel이 지원하는 sleep state를 나타내는 string 목록이 있습니다. 이 string 중 하나를 쓰면 kernel은 해당 string이 나타내는 sleep state로 system을 전환하기 시작합니다.
특히 `disk`, `freeze`, `standby` string은 각각 Hibernation, Suspend-to-Idle, Standby를 나타냅니다. `mem` string은 아래에서 설명하는 `mem_sleep` file 내용에 따라 해석됩니다.
Kernel이 어떤 system sleep state도 지원하지 않으면 `state` file은 존재하지 않습니다.
`mem_sleep` suspend 방식 선택
177-195`mem_sleep` file에는 지원되는 system suspend 방식의 string 목록이 있으며, userspace가 위의 `state` file에서 `mem` string과 연결할 방식을 선택할 수 있게 합니다.
이 file에 나타날 수 있는 string은 `s2idle`, `shallow`, `deep`입니다. `s2idle`은 항상 Suspend-to-Idle을 뜻하고, 관례상 `shallow`와 `deep`은 각각 Standby와 Suspend-to-RAM을 뜻합니다.
목록의 string 하나를 이 file에 쓰면 해당 suspend 방식이 `state` file의 `mem` string과 연결됩니다. 현재 `mem`과 연결된 suspend 방식을 나타내는 string은 square bracket 안에 표시됩니다.
Kernel이 system suspend를 지원하지 않으면 `mem_sleep` file은 존재하지 않습니다.
`disk` hibernation mode
196-244`disk` file은 Hibernation, 즉 Suspend-to-Disk의 operating mode를 제어합니다. 구체적으로 hibernation image를 만든 뒤 kernel이 무엇을 할지 지정합니다. 이 file을 읽으면 다음과 같이 encode된 지원 option 목록을 반환합니다.
`platform`은 system을 ACPI S4 같은 특별한 low-power state로 전환합니다. 추가 wakeup option을 제공하고, wakeup 뒤 platform firmware가 단순화된 initialization path를 사용하도록 할 수 있습니다. Hibernation image를 만든 뒤 system을 sleep 상태로 전환하는 특별한 mechanism을 platform이 제공할 때만 사용할 수 있으며, ACPI platform은 일반적으로 이를 제공합니다.
`shutdown`은 system의 power를 끕니다.
`reboot`는 system을 reboot하며 주로 진단에 유용합니다.
`suspend`는 hybrid system suspend입니다. 위에서 설명한 `mem_sleep` file을 통해 선택한 suspend sleep state로 system을 전환합니다. 그 상태에서 system이 성공적으로 wakeup되면 hibernation image를 버리고 계속 실행합니다. 그렇지 않으면 image를 사용해 이전 system state를 복구합니다. System suspend가 지원될 때 사용할 수 있습니다.
`test_resume`은 진단 작업입니다. System이 방금 hibernation에서 wakeup했고 현재 실행 중인 kernel instance가 restore kernel인 것처럼 image를 load한 뒤 전체 system resume를 수행합니다.
위 string 중 하나를 `disk` file에 쓰면 그 string이 나타내는 option을 선택합니다. 현재 선택된 option은 square bracket 안에 표시됩니다.
Square bracket으로 표시된 작업은 `/sys/power/state`에 `disk`를 써서 hibernation을 시작했을 때 image를 만들고 저장한 다음 수행됩니다. Kernel이 Hibernation을 지원하지 않으면 `disk` file은 존재하지 않습니다.
`image_size`와 `pm_trace`
245-273`image_size` file은 hibernation image의 크기를 제어합니다. Byte 단위 image 크기의 best-effort upper limit로 사용할 non-negative integer string을 쓸 수 있습니다.
Hibernation core는 image 크기가 그 수를 넘지 않도록 최선을 다합니다. 달성할 수 없더라도 hibernation image는 계속 만들어지며 가능한 한 작게 생성됩니다. 특히 이 file에 `0`을 쓰면 hibernation image 크기를 최소화합니다.
`image_size`를 읽으면 현재 image size limit을 반환합니다. 기본값은 available RAM 크기의 약 2/5입니다.
`pm_trace` file은 reboot를 거쳐 마지막 suspend 또는 resume event point를 RTC memory에 보존하는 `PM trace` mechanism을 제어합니다. System suspend나 resume 중 device driver failure로 발생하는 hard lockup 또는 reboot를 더 효과적으로 debug하는 데 도움이 됩니다.
`pm_trace`에 `1`이 들어 있으면 각 suspend/resume event point의 fingerprint를 차례로 RTC memory에 저장합니다. 실제 RTC 정보를 덮어쓰므로 저장 직후 system crash가 발생해도 fingerprint가 남고, 나중에 crash를 일으킨 driver를 식별하는 데 사용할 수 있습니다.
기본값은 `0`입니다. Nonzero integer를 나타내는 string을 쓰면 `1`로 바꿀 수 있습니다.
절전 상태 진입 방법과 기본값
274-291Suspend-to-Idle에는 두 가지 진입 방법이 있습니다. 첫째, `/sys/power/state`에 `freeze`를 직접 씁니다. 둘째, `/sys/power/mem_sleep`에 `s2idle`을 쓴 뒤 `/sys/power/state`에 `mem`을 씁니다. Platform이 Standby를 지원한다면 Standby에도 두 방법이 있습니다. `/sys/power/state`에 `standby`를 쓰거나, `/sys/power/mem_sleep`에 `shallow`를 쓰고 `/sys/power/state`에 `mem`을 씁니다. Suspend-to-RAM에는 한 가지 방법만 있으며 `/sys/power/mem_sleep`에 `deep`을 쓰고 `/sys/power/state`에 `mem`을 씁니다.
`/sys/power/mem_sleep`에 아무것도 쓰지 않았을 때 사용하는 기본 suspend 방식은 대다수 Suspend-to-RAM 지원 system에서 `deep`이고, 그렇지 않으면 `s2idle`입니다. Kernel command line의 `mem_sleep_default` parameter로 이를 override할 수 있습니다. 일부 ACPI system에서는 ACPI table 정보에 따라 Suspend-to-RAM을 원칙적으로 지원해도 기본값이 `s2idle`일 수 있습니다.
요약과 해설
sleep-states.rst:1-291Linux의 system sleep은 resume latency와 power 절감 정도가 다른 네 상태로 나뉩니다. Suspend-to-Idle은 software 중심의 가벼운 상태이고, Standby와 Suspend-to-RAM은 platform 지원을 더 많이 사용하며, Hibernation은 memory image를 persistent storage에 저장합니다.
운영 시에는 `/sys/power/state`의 명령과 `/sys/power/mem_sleep`의 선택을 구분해야 합니다. Hibernation은 `/sys/power/disk` mode, image size, `pm_trace`까지 별도로 관리합니다.