powercap.rst 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262
  1. =======================
  2. Power Capping Framework
  3. =======================
  4. The power capping framework provides a consistent interface between the kernel
  5. and the user space that allows power capping drivers to expose the settings to
  6. user space in a uniform way.
  7. Terminology
  8. ===========
  9. The framework exposes power capping devices to user space via sysfs in the
  10. form of a tree of objects. The objects at the root level of the tree represent
  11. 'control types', which correspond to different methods of power capping. For
  12. example, the intel-rapl control type represents the Intel "Running Average
  13. Power Limit" (RAPL) technology, whereas the 'idle-injection' control type
  14. corresponds to the use of idle injection for controlling power.
  15. Power zones represent different parts of the system, which can be controlled and
  16. monitored using the power capping method determined by the control type the
  17. given zone belongs to. They each contain attributes for monitoring power, as
  18. well as controls represented in the form of power constraints. If the parts of
  19. the system represented by different power zones are hierarchical (that is, one
  20. bigger part consists of multiple smaller parts that each have their own power
  21. controls), those power zones may also be organized in a hierarchy with one
  22. parent power zone containing multiple subzones and so on to reflect the power
  23. control topology of the system. In that case, it is possible to apply power
  24. capping to a set of devices together using the parent power zone and if more
  25. fine grained control is required, it can be applied through the subzones.
  26. Example sysfs interface tree::
  27. /sys/devices/virtual/powercap
  28. └──intel-rapl
  29. ├──intel-rapl:0
  30. │   ├──constraint_0_name
  31. │   ├──constraint_0_power_limit_uw
  32. │   ├──constraint_0_time_window_us
  33. │   ├──constraint_1_name
  34. │   ├──constraint_1_power_limit_uw
  35. │   ├──constraint_1_time_window_us
  36. │   ├──device -> ../../intel-rapl
  37. │   ├──energy_uj
  38. │   ├──intel-rapl:0:0
  39. │   │   ├──constraint_0_name
  40. │   │   ├──constraint_0_power_limit_uw
  41. │   │   ├──constraint_0_time_window_us
  42. │   │   ├──constraint_1_name
  43. │   │   ├──constraint_1_power_limit_uw
  44. │   │   ├──constraint_1_time_window_us
  45. │   │   ├──device -> ../../intel-rapl:0
  46. │   │   ├──energy_uj
  47. │   │   ├──max_energy_range_uj
  48. │   │   ├──name
  49. │   │   ├──enabled
  50. │   │   ├──power
  51. │   │   │   ├──async
  52. │   │   │   []
  53. │   │   ├──subsystem -> ../../../../../../class/power_cap
  54. │   │   └──uevent
  55. │   ├──intel-rapl:0:1
  56. │   │   ├──constraint_0_name
  57. │   │   ├──constraint_0_power_limit_uw
  58. │   │   ├──constraint_0_time_window_us
  59. │   │   ├──constraint_1_name
  60. │   │   ├──constraint_1_power_limit_uw
  61. │   │   ├──constraint_1_time_window_us
  62. │   │   ├──device -> ../../intel-rapl:0
  63. │   │   ├──energy_uj
  64. │   │   ├──max_energy_range_uj
  65. │   │   ├──name
  66. │   │   ├──enabled
  67. │   │   ├──power
  68. │   │   │   ├──async
  69. │   │   │   []
  70. │   │   ├──subsystem -> ../../../../../../class/power_cap
  71. │   │   └──uevent
  72. │   ├──max_energy_range_uj
  73. │   ├──max_power_range_uw
  74. │   ├──name
  75. │   ├──enabled
  76. │   ├──power
  77. │   │   ├──async
  78. │   │   []
  79. │   ├──subsystem -> ../../../../../class/power_cap
  80. │   ├──enabled
  81. │   ├──uevent
  82. ├──intel-rapl:1
  83. │   ├──constraint_0_name
  84. │   ├──constraint_0_power_limit_uw
  85. │   ├──constraint_0_time_window_us
  86. │   ├──constraint_1_name
  87. │   ├──constraint_1_power_limit_uw
  88. │   ├──constraint_1_time_window_us
  89. │   ├──device -> ../../intel-rapl
  90. │   ├──energy_uj
  91. │   ├──intel-rapl:1:0
  92. │   │   ├──constraint_0_name
  93. │   │   ├──constraint_0_power_limit_uw
  94. │   │   ├──constraint_0_time_window_us
  95. │   │   ├──constraint_1_name
  96. │   │   ├──constraint_1_power_limit_uw
  97. │   │   ├──constraint_1_time_window_us
  98. │   │   ├──device -> ../../intel-rapl:1
  99. │   │   ├──energy_uj
  100. │   │   ├──max_energy_range_uj
  101. │   │   ├──name
  102. │   │   ├──enabled
  103. │   │   ├──power
  104. │   │   │   ├──async
  105. │   │   │   []
  106. │   │   ├──subsystem -> ../../../../../../class/power_cap
  107. │   │   └──uevent
  108. │   ├──intel-rapl:1:1
  109. │   │   ├──constraint_0_name
  110. │   │   ├──constraint_0_power_limit_uw
  111. │   │   ├──constraint_0_time_window_us
  112. │   │   ├──constraint_1_name
  113. │   │   ├──constraint_1_power_limit_uw
  114. │   │   ├──constraint_1_time_window_us
  115. │   │   ├──device -> ../../intel-rapl:1
  116. │   │   ├──energy_uj
  117. │   │   ├──max_energy_range_uj
  118. │   │   ├──name
  119. │   │   ├──enabled
  120. │   │   ├──power
  121. │   │   │   ├──async
  122. │   │   │   []
  123. │   │   ├──subsystem -> ../../../../../../class/power_cap
  124. │   │   └──uevent
  125. │   ├──max_energy_range_uj
  126. │   ├──max_power_range_uw
  127. │   ├──name
  128. │   ├──enabled
  129. │   ├──power
  130. │   │   ├──async
  131. │   │   []
  132. │   ├──subsystem -> ../../../../../class/power_cap
  133. │   ├──uevent
  134. ├──power
  135. │   ├──async
  136. │   []
  137. ├──subsystem -> ../../../../class/power_cap
  138. ├──enabled
  139. └──uevent
  140. The above example illustrates a case in which the Intel RAPL technology,
  141. available in Intel® IA-64 and IA-32 Processor Architectures, is used. There is one
  142. control type called intel-rapl which contains two power zones, intel-rapl:0 and
  143. intel-rapl:1, representing CPU packages. Each of these power zones contains
  144. two subzones, intel-rapl:j:0 and intel-rapl:j:1 (j = 0, 1), representing the
  145. "core" and the "uncore" parts of the given CPU package, respectively. All of
  146. the zones and subzones contain energy monitoring attributes (energy_uj,
  147. max_energy_range_uj) and constraint attributes (constraint_*) allowing controls
  148. to be applied (the constraints in the 'package' power zones apply to the whole
  149. CPU packages and the subzone constraints only apply to the respective parts of
  150. the given package individually). Since Intel RAPL doesn't provide instantaneous
  151. power value, there is no power_uw attribute.
  152. In addition to that, each power zone contains a name attribute, allowing the
  153. part of the system represented by that zone to be identified.
  154. For example::
  155. cat /sys/class/power_cap/intel-rapl/intel-rapl:0/name
  156. package-0
  157. ---------
  158. Depending on different power zones, the Intel RAPL technology allows
  159. one or multiple constraints like short term, long term and peak power,
  160. with different time windows to be applied to each power zone.
  161. All the zones contain attributes representing the constraint names,
  162. power limits and the sizes of the time windows. Note that time window
  163. is not applicable to peak power. Here, constraint_j_* attributes
  164. correspond to the jth constraint (j = 0,1,2).
  165. For example::
  166. constraint_0_name
  167. constraint_0_power_limit_uw
  168. constraint_0_time_window_us
  169. constraint_1_name
  170. constraint_1_power_limit_uw
  171. constraint_1_time_window_us
  172. constraint_2_name
  173. constraint_2_power_limit_uw
  174. constraint_2_time_window_us
  175. Power Zone Attributes
  176. =====================
  177. Monitoring attributes
  178. ---------------------
  179. energy_uj (rw)
  180. Current energy counter in micro joules. Write "0" to reset.
  181. If the counter can not be reset, then this attribute is read only.
  182. max_energy_range_uj (ro)
  183. Range of the above energy counter in micro-joules.
  184. power_uw (ro)
  185. Current power in micro watts.
  186. max_power_range_uw (ro)
  187. Range of the above power value in micro-watts.
  188. name (ro)
  189. Name of this power zone.
  190. It is possible that some domains have both power ranges and energy counter ranges;
  191. however, only one is mandatory.
  192. Constraints
  193. -----------
  194. constraint_X_power_limit_uw (rw)
  195. Power limit in micro watts, which should be applicable for the
  196. time window specified by "constraint_X_time_window_us".
  197. constraint_X_time_window_us (rw)
  198. Time window in micro seconds.
  199. constraint_X_name (ro)
  200. An optional name of the constraint
  201. constraint_X_max_power_uw(ro)
  202. Maximum allowed power in micro watts.
  203. constraint_X_min_power_uw(ro)
  204. Minimum allowed power in micro watts.
  205. constraint_X_max_time_window_us(ro)
  206. Maximum allowed time window in micro seconds.
  207. constraint_X_min_time_window_us(ro)
  208. Minimum allowed time window in micro seconds.
  209. Except power_limit_uw and time_window_us other fields are optional.
  210. Common zone and control type attributes
  211. ---------------------------------------
  212. enabled (rw): Enable/Disable controls at zone level or for all zones using
  213. a control type.
  214. Power Cap Client Driver Interface
  215. =================================
  216. The API summary:
  217. Call powercap_register_control_type() to register control type object.
  218. Call powercap_register_zone() to register a power zone (under a given
  219. control type), either as a top-level power zone or as a subzone of another
  220. power zone registered earlier.
  221. The number of constraints in a power zone and the corresponding callbacks have
  222. to be defined prior to calling powercap_register_zone() to register that zone.
  223. To Free a power zone call powercap_unregister_zone().
  224. To free a control type object call powercap_unregister_control_type().
  225. Detailed API can be generated using kernel-doc on include/linux/powercap.h.