xref: /netbsd-src/share/man/man4/acpicpu.4 (revision cef8759bd76c1b621f8eab8faa6f208faabc2e15)
1.\" $NetBSD: acpicpu.4,v 1.35 2018/08/31 19:34:44 sevan Exp $
2.\"
3.\" Copyright (c) 2010 Jukka Ruohonen <jruohonen@iki.fi>
4.\" All rights reserved.
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:
9.\" 1. Redistributions of source code must retain the above copyright
10.\"    notice, this list of conditions and the following disclaimer.
11.\" 2. Neither the name of the author nor the names of any
12.\"    contributors may be used to endorse or promote products derived
13.\"    from this software without specific prior written permission.
14.\"
15.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS
16.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
17.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
18.\" PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
19.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
20.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
21.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
22.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
23.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
24.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
25.\" POSSIBILITY OF SUCH DAMAGE.
26.\"
27.Dd August 31, 2018
28.Dt ACPICPU 4
29.Os
30.Sh NAME
31.Nm acpicpu
32.Nd ACPI CPU
33.Sh SYNOPSIS
34.Cd "acpicpu* at cpu?"
35.Sh DESCRIPTION
36The
37.Nm
38device driver supports certain processor features that are
39either only available via
40.Tn ACPI
41or that require
42.Tn ACPI
43to function properly.
44Typically the
45.Tn ACPI
46processor functionality is grouped into so-called C-, P-, and T-states.
47.Ss C-states
48The processor power states, or C-states,
49are low-power modes that can be used when the
50.Tn CPU
51is idle.
52The idea is not new: already in the
53.Tn 80486
54processor a specific instruction
55.Pq Tn HLT
56was used for this purpose.
57This was later accompanied by a pair of other instructions
58.Pq Tn MONITOR , MWAIT .
59By default,
60.Nx
61may use either one; see the
62.Ic machdep.idle-mechanism
63.Xr sysctl 8
64variable.
65.Tn ACPI
66provides the latest amendment.
67.Pp
68The following C-states are typically available.
69Additional processor or vendor specific
70states (C4, ..., Cn) are handled internally by
71.Nm .
72.Bl -tag -width C1 -offset indent
73.It Dv C0
74This is the normal state of a processor; the
75.Tn CPU
76is busy executing instructions.
77.It Dv C1
78This is the state that is typically reached via the mentioned
79.Tn x86
80instructions.
81On a typical processor,
82.Dv C1
83turns off the main internal
84.Tn CPU
85clock, leaving
86.Tn APIC
87running at full speed.
88The
89.Tn CPU
90is free to temporarily leave the state to deal with important requests.
91.It Dv C2
92The main difference between
93.Dv C1
94and
95.Dv C2
96lies in the internal hardware entry method of the processor.
97While less power is expected to be consumed than in
98.Dv C1 ,
99the bus interface unit is still running.
100But depending on the processor, the local
101.Tn APIC
102timer may be stopped.
103Like with
104.Dv C1 ,
105entering and exiting the state are expected to be fast operations.
106.It Dv C3
107This is the deepest conventional state.
108Parts of the
109.Tn CPU
110are actively powered down.
111The internal
112.Tn CPU
113clock is stopped.
114The local
115.Tn APIC
116timer is stopped.
117Depending on the processor, additional timers such as
118.Xr x86/tsc 9
119may be stopped.
120Processor caches may be flushed.
121Entry and exit latencies are expected to be high; the
122.Tn CPU
123can no longer
124.Dq quickly
125respond to bus activity or other interruptions.
126.El
127.Pp
128Each state has a latency associated with entry and exit.
129The higher the state, the lower the power consumption, and
130the higher the potential performance costs.
131.Pp
132The
133.Nm
134driver tries to balance the latency
135constraints when choosing the appropriate state.
136One of the checks involves bus master activity;
137if such activity is detected, a lower state is used.
138It is known that particularly
139.Xr usb 4
140may cause high activity even when not in use.
141If maximum power savings are desirable,
142it may be necessary to use a custom kernel without
143.Tn USB
144support.
145And generally: to save power with C-states, one should
146avoid polling, both in userland and in the kernel.
147.Ss P-states
148The processor performance states, or P-states, are used to
149control the clock frequencies and voltages of a
150.Tn CPU .
151Underneath the abstractions of
152.Tn ACPI ,
153P-states are associated with such technologies as
154.Dq SpeedStep
155.Pq Intel ,
156.Dq PowerNow!
157.Pq Tn AMD ,
158and
159.Dq PowerSaver
160.Pq VIA .
161.Pp
162The P0-state is always the highest operating
163frequency supported by the processor.
164The number of additional P-states may vary across processors and vendors.
165Each higher numbered P-state represents lower
166clock frequencies and hence lower power consumption.
167Note that while
168.Nm
169always uses the exact frequencies internally,
170the user-visible values reported by
171.Tn ACPI
172may be rounded or approximated by the vendor.
173.Pp
174Unlike conventional
175.Tn CPU
176frequency management,
177.Tn ACPI
178provides support for Dynamic Voltage and Frequency Scaling
179.Pq Tn DVFS .
180Among other things,
181this means that the firmware may request the implementation to
182dynamically scale the presently supported maximum or minimum clock frequency.
183For example, if
184.Xr acpiacad 4
185is disconnected, the maximum available frequency may be lowered.
186By default,
187the
188.Nx
189implementation may manipulate the frequencies
190according to the notifications from the firmware.
191.Ss T-states
192Processor T-states, or
193.Dq throttling states ,
194can be used to actively modulate the
195time a processor is allowed to execute.
196Outside the
197.Tn ACPI
198nomenclature, throttling and T-states may be known as
199.Dq on-demand clock modulation
200.Pq Tn ODCM .
201.Pp
202The concept of
203.Dq duty cycle
204is relevant to T-states.
205It is generally defined to be a fraction of time that a system is in an
206.Dq active
207state.
208The T0-state has always a duty cycle of 100 \&%,
209and thus, comparable to the C0-state, the processor is fully active.
210Each additional higher-numbered T-state indicates lower duty cycles.
211At most eight T-states may be available, although also T-states use
212.Tn DVFS .
213.Pp
214The duty cycle does not refer to the actual clock signal,
215but to the time period in which the clock signal is allowed
216to drive the processor chip.
217For instance, if a T-state has a duty cycle of 75 \&%, the
218.Tn CPU
219runs at the same clock frequency and uses the same voltage,
220but 25 \&% of the time the
221.Tn CPU
222is forced to idle.
223Because of this, the use of T-states may
224severely affect system performance.
225.Pp
226There are two typical situations for throttling:
227power management and thermal control.
228As a technique to save power,
229T-states are largely an artifact from the past.
230There was a short period in the x86 lineage when P-states
231were not yet available and throttling was considered
232as an option to modulate the processor power consumption.
233The approach was however quickly abandoned.
234In modern x86 systems P-states should be preferred in all circumstances.
235It is also more beneficial to move from the C0-state
236to deeper C-states than it is to actively force down the
237duty cycle of a processor.
238.Pp
239But T-states have retained their use as a last line
240of defense against critical thermal conditions.
241Many x86 processors include a catastrophic shutdown detector.
242When the processor core temperature reaches this factory defined trip-point,
243the processor execution is halted without any software control.
244Before this fatal condition, it is possible to use throttling
245for a short period of time in order to force the temperatures to lower levels.
246The thermal control modulation is typically started only when
247the system is in the highest-power P-state and
248a high temperature situation exists.
249After the temperatures have returned to non-critical levels,
250the modulation ceases.
251.Ss System Control Variables
252The
253.Nm
254driver uses the same
255.Xr sysctl 8
256controls for P-states as the ones provided by
257.Xr est 4
258and
259.Xr powernow 4 .
260Depending on the processor, the second-level node is either
261.Ic machdep.est
262or
263.Ic machdep.powernow .
264Please note that future versions of
265.Nm
266may however remove these system control variables without further notice.
267.Pp
268In addition, the following two variables are available.
269.Bl -tag -width "hw.acpi.cpu.dynamic" -offset indent
270.It Ic hw.acpi.cpu.dynamic
271A boolean that controls whether the states are allowed to change dynamically.
272When enabled, C-, P-, and T-states may all change at runtime, and
273.Nm
274may also take actions based on requests from the firmware.
275.It Ic hw.acpi.cpu.passive
276A boolean that enables or disables automatic processor thermal management via
277.Xr acpitz 4 .
278.El
279.Ss Statistics
280The
281.Nm
282driver uses event counters to track the times
283a processor has entered a given state.
284It is possible to view the statistics by using
285.Xr vmstat 1
286(with the
287.Fl e
288flag).
289.Sh SEE ALSO
290.Xr acpi 4 ,
291.Xr acpitz 4 ,
292.Xr est 4 ,
293.Xr odcm 4 ,
294.Xr powernow 4 ,
295.Xr cpu_idle 9
296.Rs
297.%A Etienne Le Sueur
298.%A Gernot Heiser
299.%T Dynamic Voltage and Frequency Scaling: The Laws of Diminishing Returns
300.%O Proceedings of the 2010 Workshop on \
301Power Aware Computing and Systems (HotPower'10)
302.%D October, 2010
303.%U http://www.ertos.nicta.com.au/publications/papers/LeSueur_Heiser_10.pdf
304.Re
305.Rs
306.%A David C. Snowdon
307.%T Operating System Directed Power Management
308.%O PhD Thesis
309.%I School of Computer Science and Engineering, University of New South Wales
310.%D March, 2010
311.%U http://ertos.nicta.com.au/publications/papers/Snowdon:phd.pdf
312.Re
313.Rs
314.%A Microsoft Corporation
315.%T Windows Native Processor Performance Control
316.%N Version 1.1a
317.%D November, 2002
318.%U http://msdn.microsoft.com/en-us/windows/hardware/gg463343
319.Re
320.Rs
321.%A Venkatesh Pallipadi
322.%A Alexey Starikovskiy
323.%T The Ondemand Governor. Past, Present, and Future
324.%I Intel Open Source Technology Center
325.%O Proceedings of the Linux Symposium
326.%D July, 2006
327.%U http://www.kernel.org/doc/ols/2006/ols2006v2-pages-223-238.pdf
328.Re
329.Sh HISTORY
330The
331.Nm
332device driver appeared in
333.Nx 6.0 .
334.Sh AUTHORS
335.An Jukka Ruohonen
336.Aq jruohonen@iki.fi
337.Sh CAVEATS
338At least the following caveats can be mentioned.
339.Bl -bullet
340.It
341It is currently only safe to use
342.Dv C1
343on
344.Nx .
345All other C-states are disabled by default.
346.It
347Processor thermal control (see
348.Xr acpitz 4 )
349is not yet supported.
350.It
351Depending on the processor, changes in C-, P-,
352and T-states may all skew timers and counters such as
353.Xr x86/tsc 9 .
354This is neither handled by
355.Nm
356nor by
357.Xr est 4
358or
359.Xr powernow 4 .
360.It
361There is currently neither a well-defined, machine-independent
362.Tn API
363for processor performance management nor a
364.Dq governor
365for different policies.
366It is only possible to control the
367.Tn CPU
368frequencies from userland.
369.El
370