1=======================
2Intel Powerclamp Driver
3=======================
4
5By:
6  - Arjan van de Ven <arjan@linux.intel.com>
7  - Jacob Pan <jacob.jun.pan@linux.intel.com>
8
9.. Contents:
10
11	(*) Introduction
12	    - Goals and Objectives
13
14	(*) Theory of Operation
15	    - Idle Injection
16	    - Calibration
17
18	(*) Performance Analysis
19	    - Effectiveness and Limitations
20	    - Power vs Performance
21	    - Scalability
22	    - Calibration
23	    - Comparison with Alternative Techniques
24
25	(*) Usage and Interfaces
26	    - Generic Thermal Layer (sysfs)
27	    - Kernel APIs (TBD)
28
29	(*) Module Parameters
30
31INTRODUCTION
32============
33
34Consider the situation where a system’s power consumption must be
35reduced at runtime, due to power budget, thermal constraint, or noise
36level, and where active cooling is not preferred. Software managed
37passive power reduction must be performed to prevent the hardware
38actions that are designed for catastrophic scenarios.
39
40Currently, P-states, T-states (clock modulation), and CPU offlining
41are used for CPU throttling.
42
43On Intel CPUs, C-states provide effective power reduction, but so far
44they’re only used opportunistically, based on workload. With the
45development of intel_powerclamp driver, the method of synchronizing
46idle injection across all online CPU threads was introduced. The goal
47is to achieve forced and controllable C-state residency.
48
49Test/Analysis has been made in the areas of power, performance,
50scalability, and user experience. In many cases, clear advantage is
51shown over taking the CPU offline or modulating the CPU clock.
52
53
54THEORY OF OPERATION
55===================
56
57Idle Injection
58--------------
59
60On modern Intel processors (Nehalem or later), package level C-state
61residency is available in MSRs, thus also available to the kernel.
62
63These MSRs are::
64
65      #define MSR_PKG_C2_RESIDENCY      0x60D
66      #define MSR_PKG_C3_RESIDENCY      0x3F8
67      #define MSR_PKG_C6_RESIDENCY      0x3F9
68      #define MSR_PKG_C7_RESIDENCY      0x3FA
69
70If the kernel can also inject idle time to the system, then a
71closed-loop control system can be established that manages package
72level C-state. The intel_powerclamp driver is conceived as such a
73control system, where the target set point is a user-selected idle
74ratio (based on power reduction), and the error is the difference
75between the actual package level C-state residency ratio and the target idle
76ratio.
77
78Injection is controlled by high priority kernel threads, spawned for
79each online CPU.
80
81These kernel threads, with SCHED_FIFO class, are created to perform
82clamping actions of controlled duty ratio and duration. Each per-CPU
83thread synchronizes its idle time and duration, based on the rounding
84of jiffies, so accumulated errors can be prevented to avoid a jittery
85effect. Threads are also bound to the CPU such that they cannot be
86migrated, unless the CPU is taken offline. In this case, threads
87belong to the offlined CPUs will be terminated immediately.
88
89Running as SCHED_FIFO and relatively high priority, also allows such
90scheme to work for both preemptable and non-preemptable kernels.
91Alignment of idle time around jiffies ensures scalability for HZ
92values. This effect can be better visualized using a Perf timechart.
93The following diagram shows the behavior of kernel thread
94kidle_inject/cpu. During idle injection, it runs monitor/mwait idle
95for a given "duration", then relinquishes the CPU to other tasks,
96until the next time interval.
97
98The NOHZ schedule tick is disabled during idle time, but interrupts
99are not masked. Tests show that the extra wakeups from scheduler tick
100have a dramatic impact on the effectiveness of the powerclamp driver
101on large scale systems (Westmere system with 80 processors).
102
103::
104
105  CPU0
106		    ____________          ____________
107  kidle_inject/0   |   sleep    |  mwait |  sleep     |
108	  _________|            |________|            |_______
109				 duration
110  CPU1
111		    ____________          ____________
112  kidle_inject/1   |   sleep    |  mwait |  sleep     |
113	  _________|            |________|            |_______
114				^
115				|
116				|
117				roundup(jiffies, interval)
118
119Only one CPU is allowed to collect statistics and update global
120control parameters. This CPU is referred to as the controlling CPU in
121this document. The controlling CPU is elected at runtime, with a
122policy that favors BSP, taking into account the possibility of a CPU
123hot-plug.
124
125In terms of dynamics of the idle control system, package level idle
126time is considered largely as a non-causal system where its behavior
127cannot be based on the past or current input. Therefore, the
128intel_powerclamp driver attempts to enforce the desired idle time
129instantly as given input (target idle ratio). After injection,
130powerclamp monitors the actual idle for a given time window and adjust
131the next injection accordingly to avoid over/under correction.
132
133When used in a causal control system, such as a temperature control,
134it is up to the user of this driver to implement algorithms where
135past samples and outputs are included in the feedback. For example, a
136PID-based thermal controller can use the powerclamp driver to
137maintain a desired target temperature, based on integral and
138derivative gains of the past samples.
139
140
141
142Calibration
143-----------
144During scalability testing, it is observed that synchronized actions
145among CPUs become challenging as the number of cores grows. This is
146also true for the ability of a system to enter package level C-states.
147
148To make sure the intel_powerclamp driver scales well, online
149calibration is implemented. The goals for doing such a calibration
150are:
151
152a) determine the effective range of idle injection ratio
153b) determine the amount of compensation needed at each target ratio
154
155Compensation to each target ratio consists of two parts:
156
157	a) steady state error compensation
158
159	   This is to offset the error occurring when the system can
160	   enter idle without extra wakeups (such as external interrupts).
161
162	b) dynamic error compensation
163
164	   When an excessive amount of wakeups occurs during idle, an
165	   additional idle ratio can be added to quiet interrupts, by
166	   slowing down CPU activities.
167
168A debugfs file is provided for the user to examine compensation
169progress and results, such as on a Westmere system::
170
171  [jacob@nex01 ~]$ cat
172  /sys/kernel/debug/intel_powerclamp/powerclamp_calib
173  controlling cpu: 0
174  pct confidence steady dynamic (compensation)
175  0       0       0       0
176  1       1       0       0
177  2       1       1       0
178  3       3       1       0
179  4       3       1       0
180  5       3       1       0
181  6       3       1       0
182  7       3       1       0
183  8       3       1       0
184  ...
185  30      3       2       0
186  31      3       2       0
187  32      3       1       0
188  33      3       2       0
189  34      3       1       0
190  35      3       2       0
191  36      3       1       0
192  37      3       2       0
193  38      3       1       0
194  39      3       2       0
195  40      3       3       0
196  41      3       1       0
197  42      3       2       0
198  43      3       1       0
199  44      3       1       0
200  45      3       2       0
201  46      3       3       0
202  47      3       0       0
203  48      3       2       0
204  49      3       3       0
205
206Calibration occurs during runtime. No offline method is available.
207Steady state compensation is used only when confidence levels of all
208adjacent ratios have reached satisfactory level. A confidence level
209is accumulated based on clean data collected at runtime. Data
210collected during a period without extra interrupts is considered
211clean.
212
213To compensate for excessive amounts of wakeup during idle, additional
214idle time is injected when such a condition is detected. Currently,
215we have a simple algorithm to double the injection ratio. A possible
216enhancement might be to throttle the offending IRQ, such as delaying
217EOI for level triggered interrupts. But it is a challenge to be
218non-intrusive to the scheduler or the IRQ core code.
219
220
221CPU Online/Offline
222------------------
223Per-CPU kernel threads are started/stopped upon receiving
224notifications of CPU hotplug activities. The intel_powerclamp driver
225keeps track of clamping kernel threads, even after they are migrated
226to other CPUs, after a CPU offline event.
227
228
229Performance Analysis
230====================
231This section describes the general performance data collected on
232multiple systems, including Westmere (80P) and Ivy Bridge (4P, 8P).
233
234Effectiveness and Limitations
235-----------------------------
236The maximum range that idle injection is allowed is capped at 50
237percent. As mentioned earlier, since interrupts are allowed during
238forced idle time, excessive interrupts could result in less
239effectiveness. The extreme case would be doing a ping -f to generated
240flooded network interrupts without much CPU acknowledgement. In this
241case, little can be done from the idle injection threads. In most
242normal cases, such as scp a large file, applications can be throttled
243by the powerclamp driver, since slowing down the CPU also slows down
244network protocol processing, which in turn reduces interrupts.
245
246When control parameters change at runtime by the controlling CPU, it
247may take an additional period for the rest of the CPUs to catch up
248with the changes. During this time, idle injection is out of sync,
249thus not able to enter package C- states at the expected ratio. But
250this effect is minor, in that in most cases change to the target
251ratio is updated much less frequently than the idle injection
252frequency.
253
254Scalability
255-----------
256Tests also show a minor, but measurable, difference between the 4P/8P
257Ivy Bridge system and the 80P Westmere server under 50% idle ratio.
258More compensation is needed on Westmere for the same amount of
259target idle ratio. The compensation also increases as the idle ratio
260gets larger. The above reason constitutes the need for the
261calibration code.
262
263On the IVB 8P system, compared to an offline CPU, powerclamp can
264achieve up to 40% better performance per watt. (measured by a spin
265counter summed over per CPU counting threads spawned for all running
266CPUs).
267
268Usage and Interfaces
269====================
270The powerclamp driver is registered to the generic thermal layer as a
271cooling device. Currently, it’s not bound to any thermal zones::
272
273  jacob@chromoly:/sys/class/thermal/cooling_device14$ grep . *
274  cur_state:0
275  max_state:50
276  type:intel_powerclamp
277
278cur_state allows user to set the desired idle percentage. Writing 0 to
279cur_state will stop idle injection. Writing a value between 1 and
280max_state will start the idle injection. Reading cur_state returns the
281actual and current idle percentage. This may not be the same value
282set by the user in that current idle percentage depends on workload
283and includes natural idle. When idle injection is disabled, reading
284cur_state returns value -1 instead of 0 which is to avoid confusing
285100% busy state with the disabled state.
286
287Example usage:
288
289- To inject 25% idle time::
290
291	$ sudo sh -c "echo 25 > /sys/class/thermal/cooling_device80/cur_state
292
293If the system is not busy and has more than 25% idle time already,
294then the powerclamp driver will not start idle injection. Using Top
295will not show idle injection kernel threads.
296
297If the system is busy (spin test below) and has less than 25% natural
298idle time, powerclamp kernel threads will do idle injection. Forced
299idle time is accounted as normal idle in that common code path is
300taken as the idle task.
301
302In this example, 24.1% idle is shown. This helps the system admin or
303user determine the cause of slowdown, when a powerclamp driver is in action::
304
305
306  Tasks: 197 total,   1 running, 196 sleeping,   0 stopped,   0 zombie
307  Cpu(s): 71.2%us,  4.7%sy,  0.0%ni, 24.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
308  Mem:   3943228k total,  1689632k used,  2253596k free,    74960k buffers
309  Swap:  4087804k total,        0k used,  4087804k free,   945336k cached
310
311    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
312   3352 jacob     20   0  262m  644  428 S  286  0.0   0:17.16 spin
313   3341 root     -51   0     0    0    0 D   25  0.0   0:01.62 kidle_inject/0
314   3344 root     -51   0     0    0    0 D   25  0.0   0:01.60 kidle_inject/3
315   3342 root     -51   0     0    0    0 D   25  0.0   0:01.61 kidle_inject/1
316   3343 root     -51   0     0    0    0 D   25  0.0   0:01.60 kidle_inject/2
317   2935 jacob     20   0  696m 125m  35m S    5  3.3   0:31.11 firefox
318   1546 root      20   0  158m  20m 6640 S    3  0.5   0:26.97 Xorg
319   2100 jacob     20   0 1223m  88m  30m S    3  2.3   0:23.68 compiz
320
321Tests have shown that by using the powerclamp driver as a cooling
322device, a PID based userspace thermal controller can manage to
323control CPU temperature effectively, when no other thermal influence
324is added. For example, a UltraBook user can compile the kernel under
325certain temperature (below most active trip points).
326
327Module Parameters
328=================
329
330``cpumask`` (RW)
331	A bit mask of CPUs to inject idle. The format of the bitmask is same as
332	used in other subsystems like in /proc/irq/\*/smp_affinity. The mask is
333	comma separated 32 bit groups. Each CPU is one bit. For example for a 256
334	CPU system the full mask is:
335	ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff
336
337	The rightmost mask is for CPU 0-32.
338
339``max_idle`` (RW)
340	Maximum injected idle time to the total CPU time ratio in percent range
341	from 1 to 100. Even if the cooling device max_state is always 100 (100%),
342	this parameter allows to add a max idle percent limit. The default is 50,
343	to match the current implementation of powerclamp driver. Also doesn't
344	allow value more than 75, if the cpumask includes every CPU present in
345	the system.
346