1 =======================
2 Power Capping Framework
3 =======================
5 The power capping framework provides a consistent interface between the kernel
6 and the user space that allows power capping drivers to expose the settings to
7 user space in a uniform way.
12 The framework exposes power capping devices to user space via sysfs in the
13 form of a tree of objects. The objects at the root level of the tree represent
14 'control types', which correspond to different methods of power capping. For
15 example, the intel-rapl control type represents the Intel "Running Average
16 Power Limit" (RAPL) technology, whereas the 'idle-injection' control type
17 corresponds to the use of idle injection for controlling power.
19 Power zones represent different parts of the system, which can be controlled and
20 monitored using the power capping method determined by the control type the
21 given zone belongs to. They each contain attributes for monitoring power, as
22 well as controls represented in the form of power constraints. If the parts of
23 the system represented by different power zones are hierarchical (that is, one
24 bigger part consists of multiple smaller parts that each have their own power
25 controls), those power zones may also be organized in a hierarchy with one
26 parent power zone containing multiple subzones and so on to reflect the power
27 control topology of the system. In that case, it is possible to apply power
28 capping to a set of devices together using the parent power zone and if more
29 fine grained control is required, it can be applied through the subzones.
32 Example sysfs interface tree::
34 /sys/devices/virtual/powercap
37 │ ├──constraint_0_name
38 │ ├──constraint_0_power_limit_uw
39 │ ├──constraint_0_time_window_us
40 │ ├──constraint_1_name
41 │ ├──constraint_1_power_limit_uw
42 │ ├──constraint_1_time_window_us
43 │ ├──device -> ../../intel-rapl
46 │ │ ├──constraint_0_name
47 │ │ ├──constraint_0_power_limit_uw
48 │ │ ├──constraint_0_time_window_us
49 │ │ ├──constraint_1_name
50 │ │ ├──constraint_1_power_limit_uw
51 │ │ ├──constraint_1_time_window_us
52 │ │ ├──device -> ../../intel-rapl:0
54 │ │ ├──max_energy_range_uj
60 │ │ ├──subsystem -> ../../../../../../class/power_cap
63 │ │ ├──constraint_0_name
64 │ │ ├──constraint_0_power_limit_uw
65 │ │ ├──constraint_0_time_window_us
66 │ │ ├──constraint_1_name
67 │ │ ├──constraint_1_power_limit_uw
68 │ │ ├──constraint_1_time_window_us
69 │ │ ├──device -> ../../intel-rapl:0
71 │ │ ├──max_energy_range_uj
77 │ │ ├──subsystem -> ../../../../../../class/power_cap
79 │ ├──max_energy_range_uj
80 │ ├──max_power_range_uw
86 │ ├──subsystem -> ../../../../../class/power_cap
90 │ ├──constraint_0_name
91 │ ├──constraint_0_power_limit_uw
92 │ ├──constraint_0_time_window_us
93 │ ├──constraint_1_name
94 │ ├──constraint_1_power_limit_uw
95 │ ├──constraint_1_time_window_us
96 │ ├──device -> ../../intel-rapl
99 │ │ ├──constraint_0_name
100 │ │ ├──constraint_0_power_limit_uw
101 │ │ ├──constraint_0_time_window_us
102 │ │ ├──constraint_1_name
103 │ │ ├──constraint_1_power_limit_uw
104 │ │ ├──constraint_1_time_window_us
105 │ │ ├──device -> ../../intel-rapl:1
107 │ │ ├──max_energy_range_uj
113 │ │ ├──subsystem -> ../../../../../../class/power_cap
116 │ │ ├──constraint_0_name
117 │ │ ├──constraint_0_power_limit_uw
118 │ │ ├──constraint_0_time_window_us
119 │ │ ├──constraint_1_name
120 │ │ ├──constraint_1_power_limit_uw
121 │ │ ├──constraint_1_time_window_us
122 │ │ ├──device -> ../../intel-rapl:1
124 │ │ ├──max_energy_range_uj
130 │ │ ├──subsystem -> ../../../../../../class/power_cap
132 │ ├──max_energy_range_uj
133 │ ├──max_power_range_uw
139 │ ├──subsystem -> ../../../../../class/power_cap
144 ├──subsystem -> ../../../../class/power_cap
148 The above example illustrates a case in which the Intel RAPL technology,
149 available in Intel® IA-64 and IA-32 Processor Architectures, is used. There is one
150 control type called intel-rapl which contains two power zones, intel-rapl:0 and
151 intel-rapl:1, representing CPU packages. Each of these power zones contains
152 two subzones, intel-rapl:j:0 and intel-rapl:j:1 (j = 0, 1), representing the
153 "core" and the "uncore" parts of the given CPU package, respectively. All of
154 the zones and subzones contain energy monitoring attributes (energy_uj,
155 max_energy_range_uj) and constraint attributes (constraint_*) allowing controls
156 to be applied (the constraints in the 'package' power zones apply to the whole
157 CPU packages and the subzone constraints only apply to the respective parts of
158 the given package individually). Since Intel RAPL doesn't provide instantaneous
159 power value, there is no power_uw attribute.
161 In addition to that, each power zone contains a name attribute, allowing the
162 part of the system represented by that zone to be identified.
165 cat /sys/class/power_cap/intel-rapl/intel-rapl:0/name
170 Depending on different power zones, the Intel RAPL technology allows
171 one or multiple constraints like short term, long term and peak power,
172 with different time windows to be applied to each power zone.
173 All the zones contain attributes representing the constraint names,
174 power limits and the sizes of the time windows. Note that time window
175 is not applicable to peak power. Here, constraint_j_* attributes
176 correspond to the jth constraint (j = 0,1,2).
181 constraint_0_power_limit_uw
182 constraint_0_time_window_us
184 constraint_1_power_limit_uw
185 constraint_1_time_window_us
187 constraint_2_power_limit_uw
188 constraint_2_time_window_us
190 Power Zone Attributes
191 =====================
193 Monitoring attributes
194 ---------------------
197 Current energy counter in micro joules. Write "0" to reset.
198 If the counter can not be reset, then this attribute is read only.
200 max_energy_range_uj (ro)
201 Range of the above energy counter in micro-joules.
204 Current power in micro watts.
206 max_power_range_uw (ro)
207 Range of the above power value in micro-watts.
210 Name of this power zone.
212 It is possible that some domains have both power ranges and energy counter ranges;
213 however, only one is mandatory.
218 constraint_X_power_limit_uw (rw)
219 Power limit in micro watts, which should be applicable for the
220 time window specified by "constraint_X_time_window_us".
222 constraint_X_time_window_us (rw)
223 Time window in micro seconds.
225 constraint_X_name (ro)
226 An optional name of the constraint
228 constraint_X_max_power_uw(ro)
229 Maximum allowed power in micro watts.
231 constraint_X_min_power_uw(ro)
232 Minimum allowed power in micro watts.
234 constraint_X_max_time_window_us(ro)
235 Maximum allowed time window in micro seconds.
237 constraint_X_min_time_window_us(ro)
238 Minimum allowed time window in micro seconds.
240 Except power_limit_uw and time_window_us other fields are optional.
242 Common zone and control type attributes
243 ---------------------------------------
245 enabled (rw): Enable/Disable controls at zone level or for all zones using
248 Power Cap Client Driver Interface
249 =================================
253 Call powercap_register_control_type() to register control type object.
254 Call powercap_register_zone() to register a power zone (under a given
255 control type), either as a top-level power zone or as a subzone of another
256 power zone registered earlier.
257 The number of constraints in a power zone and the corresponding callbacks have
258 to be defined prior to calling powercap_register_zone() to register that zone.
260 To Free a power zone call powercap_unregister_zone().
261 To free a control type object call powercap_unregister_control_type().
262 Detailed API can be generated using kernel-doc on include/linux/powercap.h.