cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

strategies.rst (3195B)


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