~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

TOMOYO Linux Cross Reference
Linux/Documentation/admin-guide/pm/strategies.rst

Version: ~ [ linux-6.12-rc7 ] ~ [ linux-6.11.7 ] ~ [ linux-6.10.14 ] ~ [ linux-6.9.12 ] ~ [ linux-6.8.12 ] ~ [ linux-6.7.12 ] ~ [ linux-6.6.60 ] ~ [ linux-6.5.13 ] ~ [ linux-6.4.16 ] ~ [ linux-6.3.13 ] ~ [ linux-6.2.16 ] ~ [ linux-6.1.116 ] ~ [ linux-6.0.19 ] ~ [ linux-5.19.17 ] ~ [ linux-5.18.19 ] ~ [ linux-5.17.15 ] ~ [ linux-5.16.20 ] ~ [ linux-5.15.171 ] ~ [ linux-5.14.21 ] ~ [ linux-5.13.19 ] ~ [ linux-5.12.19 ] ~ [ linux-5.11.22 ] ~ [ linux-5.10.229 ] ~ [ linux-5.9.16 ] ~ [ linux-5.8.18 ] ~ [ linux-5.7.19 ] ~ [ linux-5.6.19 ] ~ [ linux-5.5.19 ] ~ [ linux-5.4.285 ] ~ [ linux-5.3.18 ] ~ [ linux-5.2.21 ] ~ [ linux-5.1.21 ] ~ [ linux-5.0.21 ] ~ [ linux-4.20.17 ] ~ [ linux-4.19.323 ] ~ [ linux-4.18.20 ] ~ [ linux-4.17.19 ] ~ [ linux-4.16.18 ] ~ [ linux-4.15.18 ] ~ [ linux-4.14.336 ] ~ [ linux-4.13.16 ] ~ [ linux-4.12.14 ] ~ [ linux-4.11.12 ] ~ [ linux-4.10.17 ] ~ [ linux-4.9.337 ] ~ [ linux-4.4.302 ] ~ [ linux-3.10.108 ] ~ [ linux-2.6.32.71 ] ~ [ linux-2.6.0 ] ~ [ linux-2.4.37.11 ] ~ [ unix-v6-master ] ~ [ ccs-tools-1.8.12 ] ~ [ policy-sample ] ~
Architecture: ~ [ i386 ] ~ [ alpha ] ~ [ m68k ] ~ [ mips ] ~ [ ppc ] ~ [ sparc ] ~ [ sparc64 ] ~

Diff markup

Differences between /Documentation/admin-guide/pm/strategies.rst (Architecture alpha) and /Documentation/admin-guide/pm/strategies.rst (Architecture i386)


  1 .. SPDX-License-Identifier: GPL-2.0                 1 .. SPDX-License-Identifier: GPL-2.0
  2 .. include:: <isonum.txt>                           2 .. include:: <isonum.txt>
  3                                                     3 
  4 ===========================                         4 ===========================
  5 Power Management Strategies                         5 Power Management Strategies
  6 ===========================                         6 ===========================
  7                                                     7 
  8 :Copyright: |copy| 2017 Intel Corporation           8 :Copyright: |copy| 2017 Intel Corporation
  9                                                     9 
 10 :Author: Rafael J. Wysocki <rafael.j.wysocki@in     10 :Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
 11                                                    11 
 12                                                    12 
 13 The Linux kernel supports two major high-level     13 The Linux kernel supports two major high-level power management strategies.
 14                                                    14 
 15 One of them is based on using global low-power     15 One of them is based on using global low-power states of the whole system in
 16 which user space code cannot be executed and t     16 which user space code cannot be executed and the overall system activity is
 17 significantly reduced, referred to as :doc:`sl     17 significantly reduced, referred to as :doc:`sleep states <sleep-states>`.  The
 18 kernel puts the system into one of these state     18 kernel puts the system into one of these states when requested by user space
 19 and the system stays in it until a special sig     19 and the system stays in it until a special signal is received from one of
 20 designated devices, triggering a transition to     20 designated devices, triggering a transition to the ``working state`` in which
 21 user space code can run.  Because sleep states     21 user space code can run.  Because sleep states are global and the whole system
 22 is affected by the state changes, this strateg     22 is affected by the state changes, this strategy is referred to as the
 23 :doc:`system-wide power management <system-wid     23 :doc:`system-wide power management <system-wide>`.
 24                                                    24 
 25 The other strategy, referred to as the :doc:`w     25 The other strategy, referred to as the :doc:`working-state power management
 26 <working-state>`, is based on adjusting the po     26 <working-state>`, is based on adjusting the power states of individual hardware
 27 components of the system, as needed, in the wo     27 components of the system, as needed, in the working state.  In consequence, if
 28 this strategy is in use, the working state of      28 this strategy is in use, the working state of the system usually does not
 29 correspond to any particular physical configur     29 correspond to any particular physical configuration of it, but can be treated as
 30 a metastate covering a range of different powe     30 a metastate covering a range of different power states of the system in which
 31 the individual components of it can be either      31 the individual components of it can be either ``active`` (in use) or
 32 ``inactive`` (idle).  If they are active, they     32 ``inactive`` (idle).  If they are active, they have to be in power states
 33 allowing them to process data and to be access     33 allowing them to process data and to be accessed by software.  In turn, if they
 34 are inactive, ideally, they should be in low-p     34 are inactive, ideally, they should be in low-power states in which they may not
 35 be accessible.                                     35 be accessible.
 36                                                    36 
 37 If all of the system components are active, th     37 If all of the system components are active, the system as a whole is regarded as
 38 "runtime active" and that situation typically      38 "runtime active" and that situation typically corresponds to the maximum power
 39 draw (or maximum energy usage) of it.  If all      39 draw (or maximum energy usage) of it.  If all of them are inactive, the system
 40 as a whole is regarded as "runtime idle" which     40 as a whole is regarded as "runtime idle" which may be very close to a sleep
 41 state from the physical system configuration a     41 state from the physical system configuration and power draw perspective, but
 42 then it takes much less time and effort to sta     42 then it takes much less time and effort to start executing user space code than
 43 for the same system in a sleep state.  However     43 for the same system in a sleep state.  However, transitions from sleep states
 44 back to the working state can only be started      44 back to the working state can only be started by a limited set of devices, so
 45 typically the system can spend much more time      45 typically the system can spend much more time in a sleep state than it can be
 46 runtime idle in one go.  For this reason, syst     46 runtime idle in one go.  For this reason, systems usually use less energy in
 47 sleep states than when they are runtime idle m     47 sleep states than when they are runtime idle most of the time.
 48                                                    48 
 49 Moreover, the two power management strategies      49 Moreover, the two power management strategies address different usage scenarios.
 50 Namely, if the user indicates that the system      50 Namely, if the user indicates that the system will not be in use going forward,
 51 for example by closing its lid (if the system      51 for example by closing its lid (if the system is a laptop), it probably should
 52 go into a sleep state at that point.  On the o     52 go into a sleep state at that point.  On the other hand, if the user simply goes
 53 away from the laptop keyboard, it probably sho     53 away from the laptop keyboard, it probably should stay in the working state and
 54 use the working-state power management in case     54 use the working-state power management in case it becomes idle, because the user
 55 may come back to it at any time and then may w     55 may come back to it at any time and then may want the system to be immediately
 56 accessible.                                        56 accessible.
                                                      

~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

kernel.org | git.kernel.org | LWN.net | Project Home | SVN repository | Mail admin

Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.

sflogo.php