xref: /netbsd-src/share/man/man4/acpicpu.4 (revision 6a493d6bc668897c91594964a732d38505b70cbb)
1.\" $NetBSD: acpicpu.4,v 1.34 2011/08/09 07:18:54 jruoho 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 6, 2011
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.Pp
73.Bl -tag -width C1 -offset indent
74.It Dv C0
75This is the normal state of a processor; the
76.Tn CPU
77is busy executing instructions.
78.It Dv C1
79This is the state that is typically reached via the mentioned
80.Tn x86
81instructions.
82On a typical processor,
83.Dv C1
84turns off the main internal
85.Tn CPU
86clock, leaving
87.Tn APIC
88running at full speed.
89The
90.Tn CPU
91is free to temporarily leave the state to deal with important requests.
92.It Dv C2
93The main difference between
94.Dv C1
95and
96.Dv C2
97lies in the internal hardware entry method of the processor.
98While less power is expected to be consumed than in
99.Dv C1 ,
100the bus interface unit is still running.
101But depending on the processor, the local
102.Tn APIC
103timer may be stopped.
104Like with
105.Dv C1 ,
106entering and exiting the state are expected to be fast operations.
107.It Dv C3
108This is the deepest conventional state.
109Parts of the
110.Tn CPU
111are actively powered down.
112The internal
113.Tn CPU
114clock is stopped.
115The local
116.Tn APIC
117timer is stopped.
118Depending on the processor, additional timers such as
119.Xr x86/tsc 9
120may be stopped.
121Processor caches may be flushed.
122Entry and exit latencies are expected to be high; the
123.Tn CPU
124can no longer
125.Dq quickly
126respond to bus activity or other interruptions.
127.El
128.Pp
129Each state has a latency associated with entry and exit.
130The higher the state, the lower the power consumption, and
131the higher the potential performance costs.
132.Pp
133The
134.Nm
135driver tries to balance the latency
136constraints when choosing the appropriate state.
137One of the checks involves bus master activity;
138if such activity is detected, a lower state is used.
139It is known that particularly
140.Xr usb 4
141may cause high activity even when not in use.
142If maximum power savings are desirable,
143it may be necessary to use a custom kernel without
144.Tn USB
145support.
146And generally: to save power with C-states, one should
147avoid polling, both in userland and in the kernel.
148.Ss P-states
149The processor performance states, or P-states, are used to
150control the clock frequencies and voltages of a
151.Tn CPU .
152Underneath the abstractions of
153.Tn ACPI ,
154P-states are associated with such technologies as
155.Dq SpeedStep
156.Pq Intel ,
157.Dq PowerNow!
158.Pq Tn AMD ,
159and
160.Dq PowerSaver
161.Pq VIA .
162.Pp
163The P0-state is always the highest operating
164frequency supported by the processor.
165The number of additional P-states may vary across processors and vendors.
166Each higher numbered P-state represents lower
167clock frequencies and hence lower power consumption.
168Note that while
169.Nm
170always uses the exact frequencies internally,
171the user-visible values reported by
172.Tn ACPI
173may be rounded or approximated by the vendor.
174.Pp
175Unlike conventional
176.Tn CPU
177frequency management,
178.Tn ACPI
179provides support for Dynamic Voltage and Frequency Scaling
180.Pq Tn DVFS .
181Among other things,
182this means that the firmware may request the implementation to
183dynamically scale the presently supported maximum or minimum clock frequency.
184For example, if
185.Xr acpiacad 4
186is disconnected, the maximum available frequency may be lowered.
187By default,
188the
189.Nx
190implementation may manipulate the frequencies
191according to the notifications from the firmware.
192.Ss T-states
193Processor T-states, or
194.Dq throttling states ,
195can be used to actively modulate the
196time a processor is allowed to execute.
197Outside the
198.Tn ACPI
199nomenclature, throttling and T-states may be known as
200.Dq on-demand clock modulation
201.Pq Tn ODCM .
202.Pp
203The concept of
204.Dq duty cycle
205is relevant to T-states.
206It is generally defined to be a fraction of time that a system is in an
207.Dq active
208state.
209The T0-state has always a duty cycle of 100 \&%,
210and thus, comparable to the C0-state, the processor is fully active.
211Each additional higher-numbered T-state indicates lower duty cycles.
212At most eight T-states may be available, although also T-states use
213.Tn DVFS .
214.Pp
215The duty cycle does not refer to the actual clock signal,
216but to the time period in which the clock signal is allowed
217to drive the processor chip.
218For instance, if a T-state has a duty cycle of 75 \&%, the
219.Tn CPU
220runs at the same clock frequency and uses the same voltage,
221but 25 \&% of the time the
222.Tn CPU
223is forced to idle.
224Because of this, the use of T-states may
225severely affect system performance.
226.Pp
227There are two typical situations for throttling:
228power management and thermal control.
229As a technique to save power,
230T-states are largely an artifact from the past.
231There was a short period in the x86 lineage when P-states
232were not yet available and throttling was considered
233as an option to modulate the processor power consumption.
234The approach was however quickly abandoned.
235In modern x86 systems P-states should be preferred in all circumstances.
236It is also more beneficial to move from the C0-state
237to deeper C-states than it is to actively force down the
238duty cycle of a processor.
239.Pp
240But T-states have retained their use as a last line
241of defense against critical thermal conditions.
242Many x86 processors include a catastrophic shutdown detector.
243When the processor core temperature reaches this factory defined trip-point,
244the processor execution is halted without any software control.
245Before this fatal condition, it is possible to use throttling
246for a short period of time in order to force the temperatures to lower levels.
247The thermal control modulation is typically started only when
248the system is in the highest-power P-state and
249a high temperature situation exists.
250After the temperatures have returned to non-critical levels,
251the modulation ceases.
252.Ss System Control Variables
253The
254.Nm
255driver uses the same
256.Xr sysctl 8
257controls for P-states as the ones provided by
258.Xr est 4
259and
260.Xr powernow 4 .
261Depending on the processor, the second-level node is either
262.Ic machdep.est
263or
264.Ic machdep.powernow .
265Please note that future versions of
266.Nm
267may however remove these system control variables without further notice.
268.Pp
269In addition, the following two variables are available.
270.Bl -tag -width "hw.acpi.cpu.dynamic" -offset indent
271.It Ic hw.acpi.cpu.dynamic
272A boolean that controls whether the states are allowed to change dynamically.
273When enabled, C-, P-, and T-states may all change at runtime, and
274.Nm
275may also take actions based on requests from the firmware.
276.It Ic hw.acpi.cpu.passive
277A boolean that enables or disables automatic processor thermal management via
278.Xr acpitz 4 .
279.El
280.Ss Statistics
281The
282.Nm
283driver uses event counters to track the times
284a processor has entered a given state.
285It is possible to view the statistics by using
286.Xr vmstat 1
287(with the
288.Fl e
289flag).
290.Sh SEE ALSO
291.Xr acpi 4 ,
292.Xr acpitz 4 ,
293.Xr est 4 ,
294.Xr odcm 4 ,
295.Xr powernow 4 ,
296.Xr cpu_idle 9
297.Rs
298.%A Etienne Le Sueur
299.%A Gernot Heiser
300.%T Dynamic Voltage and Frequency Scaling: The Laws of Diminishing Returns
301.%O Proceedings of the 2010 Workshop on \
302Power Aware Computing and Systems (HotPower'10)
303.%D October, 2010
304.%U http://www.ertos.nicta.com.au/publications/papers/LeSueur_Heiser_10.pdf
305.Re
306.Rs
307.%A David C. Snowdon
308.%T Operating System Directed Power Management
309.%O PhD Thesis
310.%I School of Computer Science and Engineering, University of New South Wales
311.%D March, 2010
312.%U http://ertos.nicta.com.au/publications/papers/Snowdon:phd.pdf
313.Re
314.Rs
315.%A Microsoft Corporation
316.%T Windows Native Processor Performance Control
317.%N Version 1.1a
318.%D November, 2002
319.%U http://msdn.microsoft.com/en-us/windows/hardware/gg463343
320.Re
321.Rs
322.%A Venkatesh Pallipadi
323.%A Alexey Starikovskiy
324.%T The Ondemand Governor. Past, Present, and Future
325.%I Intel Open Source Technology Center
326.%O Proceedings of the Linux Symposium
327.%D July, 2006
328.%U http://www.kernel.org/doc/ols/2006/ols2006v2-pages-223-238.pdf
329.Re
330.Sh HISTORY
331The
332.Nm
333device driver appeared in
334.Nx 6.0 .
335.Sh AUTHORS
336.An Jukka Ruohonen
337.Aq jruohonen@iki.fi
338.Sh CAVEATS
339At least the following caveats can be mentioned.
340.Bl -bullet
341.It
342It is currently only safe to use
343.Dv C1
344on
345.Nx .
346All other C-states are disabled by default.
347.It
348Processor thermal control (see
349.Xr acpitz 4 )
350is not yet supported.
351.It
352Depending on the processor, changes in C-, P-,
353and T-states may all skew timers and counters such as
354.Xr x86/tsc 9 .
355This is neither handled by
356.Nm
357nor by
358.Xr est 4
359or
360.Xr powernow 4 .
361.It
362There is currently neither a well-defined, machine-independent
363.Tn API
364for processor performance management nor a
365.Dq governor
366for different policies.
367It is only possible to control the
368.Tn CPU
369frequencies from userland.
370.El
371