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

cpu-idle-cooling.rst (7297B)


      1.. SPDX-License-Identifier: GPL-2.0
      2
      3================
      4CPU Idle Cooling
      5================
      6
      7Situation:
      8----------
      9
     10Under certain circumstances a SoC can reach a critical temperature
     11limit and is unable to stabilize the temperature around a temperature
     12control. When the SoC has to stabilize the temperature, the kernel can
     13act on a cooling device to mitigate the dissipated power. When the
     14critical temperature is reached, a decision must be taken to reduce
     15the temperature, that, in turn impacts performance.
     16
     17Another situation is when the silicon temperature continues to
     18increase even after the dynamic leakage is reduced to its minimum by
     19clock gating the component. This runaway phenomenon can continue due
     20to the static leakage. The only solution is to power down the
     21component, thus dropping the dynamic and static leakage that will
     22allow the component to cool down.
     23
     24Last but not least, the system can ask for a specific power budget but
     25because of the OPP density, we can only choose an OPP with a power
     26budget lower than the requested one and under-utilize the CPU, thus
     27losing performance. In other words, one OPP under-utilizes the CPU
     28with a power less than the requested power budget and the next OPP
     29exceeds the power budget. An intermediate OPP could have been used if
     30it were present.
     31
     32Solutions:
     33----------
     34
     35If we can remove the static and the dynamic leakage for a specific
     36duration in a controlled period, the SoC temperature will
     37decrease. Acting on the idle state duration or the idle cycle
     38injection period, we can mitigate the temperature by modulating the
     39power budget.
     40
     41The Operating Performance Point (OPP) density has a great influence on
     42the control precision of cpufreq, however different vendors have a
     43plethora of OPP density, and some have large power gap between OPPs,
     44that will result in loss of performance during thermal control and
     45loss of power in other scenarios.
     46
     47At a specific OPP, we can assume that injecting idle cycle on all CPUs
     48belong to the same cluster, with a duration greater than the cluster
     49idle state target residency, we lead to dropping the static and the
     50dynamic leakage for this period (modulo the energy needed to enter
     51this state). So the sustainable power with idle cycles has a linear
     52relation with the OPP’s sustainable power and can be computed with a
     53coefficient similar to::
     54
     55	    Power(IdleCycle) = Coef x Power(OPP)
     56
     57Idle Injection:
     58---------------
     59
     60The base concept of the idle injection is to force the CPU to go to an
     61idle state for a specified time each control cycle, it provides
     62another way to control CPU power and heat in addition to
     63cpufreq. Ideally, if all CPUs belonging to the same cluster, inject
     64their idle cycles synchronously, the cluster can reach its power down
     65state with a minimum power consumption and reduce the static leakage
     66to almost zero.  However, these idle cycles injection will add extra
     67latencies as the CPUs will have to wakeup from a deep sleep state.
     68
     69We use a fixed duration of idle injection that gives an acceptable
     70performance penalty and a fixed latency. Mitigation can be increased
     71or decreased by modulating the duty cycle of the idle injection.
     72
     73::
     74
     75     ^
     76     |
     77     |
     78     |-------                         -------
     79     |_______|_______________________|_______|___________
     80
     81     <------>
     82       idle  <---------------------->
     83                    running
     84
     85      <----------------------------->
     86              duty cycle 25%
     87
     88
     89The implementation of the cooling device bases the number of states on
     90the duty cycle percentage. When no mitigation is happening the cooling
     91device state is zero, meaning the duty cycle is 0%.
     92
     93When the mitigation begins, depending on the governor's policy, a
     94starting state is selected. With a fixed idle duration and the duty
     95cycle (aka the cooling device state), the running duration can be
     96computed.
     97
     98The governor will change the cooling device state thus the duty cycle
     99and this variation will modulate the cooling effect.
    100
    101::
    102
    103     ^
    104     |
    105     |
    106     |-------                 -------
    107     |_______|_______________|_______|___________
    108
    109     <------>
    110       idle  <-------------->
    111                running
    112
    113      <--------------------->
    114          duty cycle 33%
    115
    116
    117     ^
    118     |
    119     |
    120     |-------         -------
    121     |_______|_______|_______|___________
    122
    123     <------>
    124       idle  <------>
    125              running
    126
    127      <------------->
    128       duty cycle 50%
    129
    130The idle injection duration value must comply with the constraints:
    131
    132- It is less than or equal to the latency we tolerate when the
    133  mitigation begins. It is platform dependent and will depend on the
    134  user experience, reactivity vs performance trade off we want. This
    135  value should be specified.
    136
    137- It is greater than the idle state’s target residency we want to go
    138  for thermal mitigation, otherwise we end up consuming more energy.
    139
    140Power considerations
    141--------------------
    142
    143When we reach the thermal trip point, we have to sustain a specified
    144power for a specific temperature but at this time we consume::
    145
    146 Power = Capacitance x Voltage^2 x Frequency x Utilisation
    147
    148... which is more than the sustainable power (or there is something
    149wrong in the system setup). The ‘Capacitance’ and ‘Utilisation’ are a
    150fixed value, ‘Voltage’ and the ‘Frequency’ are fixed artificially
    151because we don’t want to change the OPP. We can group the
    152‘Capacitance’ and the ‘Utilisation’ into a single term which is the
    153‘Dynamic Power Coefficient (Cdyn)’ Simplifying the above, we have::
    154
    155 Pdyn = Cdyn x Voltage^2 x Frequency
    156
    157The power allocator governor will ask us somehow to reduce our power
    158in order to target the sustainable power defined in the device
    159tree. So with the idle injection mechanism, we want an average power
    160(Ptarget) resulting in an amount of time running at full power on a
    161specific OPP and idle another amount of time. That could be put in a
    162equation::
    163
    164 P(opp)target = ((Trunning x (P(opp)running) + (Tidle x P(opp)idle)) /
    165			(Trunning + Tidle)
    166
    167  ...
    168
    169 Tidle = Trunning x ((P(opp)running / P(opp)target) - 1)
    170
    171At this point if we know the running period for the CPU, that gives us
    172the idle injection we need. Alternatively if we have the idle
    173injection duration, we can compute the running duration with::
    174
    175 Trunning = Tidle / ((P(opp)running / P(opp)target) - 1)
    176
    177Practically, if the running power is less than the targeted power, we
    178end up with a negative time value, so obviously the equation usage is
    179bound to a power reduction, hence a higher OPP is needed to have the
    180running power greater than the targeted power.
    181
    182However, in this demonstration we ignore three aspects:
    183
    184 * The static leakage is not defined here, we can introduce it in the
    185   equation but assuming it will be zero most of the time as it is
    186   difficult to get the values from the SoC vendors
    187
    188 * The idle state wake up latency (or entry + exit latency) is not
    189   taken into account, it must be added in the equation in order to
    190   rigorously compute the idle injection
    191
    192 * The injected idle duration must be greater than the idle state
    193   target residency, otherwise we end up consuming more energy and
    194   potentially invert the mitigation effect
    195
    196So the final equation is::
    197
    198 Trunning = (Tidle - Twakeup ) x
    199		(((P(opp)dyn + P(opp)static ) - P(opp)target) / P(opp)target )