diff options
Diffstat (limited to 'static/netbsd/man4/acpicpu.4 3.html')
| -rw-r--r-- | static/netbsd/man4/acpicpu.4 3.html | 236 |
1 files changed, 236 insertions, 0 deletions
diff --git a/static/netbsd/man4/acpicpu.4 3.html b/static/netbsd/man4/acpicpu.4 3.html new file mode 100644 index 00000000..364669bc --- /dev/null +++ b/static/netbsd/man4/acpicpu.4 3.html @@ -0,0 +1,236 @@ +<table class="head"> + <tr> + <td class="head-ltitle">ACPICPU(4)</td> + <td class="head-vol">Device Drivers Manual</td> + <td class="head-rtitle">ACPICPU(4)</td> + </tr> +</table> +<div class="manual-text"> +<section class="Sh"> +<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1> +<p class="Pp"><code class="Nm">acpicpu</code> — <span class="Nd">ACPI + CPU</span></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1> +<p class="Pp"><code class="Cd">acpicpu* at cpu?</code></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1> +<p class="Pp">The <code class="Nm">acpicpu</code> device driver supports certain + processor features that are either only available via ACPI or that require + ACPI to function properly. Typically the ACPI processor functionality is + grouped into so-called C-, P-, and T-states.</p> +<section class="Ss"> +<h2 class="Ss" id="C-states"><a class="permalink" href="#C-states">C-states</a></h2> +<p class="Pp">The processor power states, or C-states, are low-power modes that + can be used when the CPU is idle. The idea is not new: already in the 80486 + processor a specific instruction (HLT) was used for this purpose. This was + later accompanied by a pair of other instructions (MONITOR, MWAIT). By + default, <span class="Ux">NetBSD</span> may use either one; see the + <code class="Ic">machdep.idle-mechanism</code> <a class="Xr">sysctl(8)</a> + variable. ACPI provides the latest amendment.</p> +<p class="Pp">The following C-states are typically available. Additional + processor or vendor specific states (C4, ..., Cn) are handled internally by + <code class="Nm">acpicpu</code>.</p> +<div class="Bd-indent"> +<dl class="Bl-tag"> + <dt id="C0"><a class="permalink" href="#C0"><code class="Dv">C0</code></a></dt> + <dd>This is the normal state of a processor; the CPU is busy executing + instructions.</dd> + <dt id="C1"><a class="permalink" href="#C1"><code class="Dv">C1</code></a></dt> + <dd>This is the state that is typically reached via the mentioned x86 + instructions. On a typical processor, <code class="Dv">C1</code> turns off + the main internal CPU clock, leaving APIC running at full speed. The CPU + is free to temporarily leave the state to deal with important + requests.</dd> + <dt id="C2"><a class="permalink" href="#C2"><code class="Dv">C2</code></a></dt> + <dd>The main difference between <code class="Dv">C1</code> and + <code class="Dv">C2</code> lies in the internal hardware entry method of + the processor. While less power is expected to be consumed than in + <code class="Dv">C1</code>, the bus interface unit is still running. But + depending on the processor, the local APIC timer may be stopped. Like with + <code class="Dv">C1</code>, entering and exiting the state are expected to + be fast operations.</dd> + <dt id="C3"><a class="permalink" href="#C3"><code class="Dv">C3</code></a></dt> + <dd>This is the deepest conventional state. Parts of the CPU are actively + powered down. The internal CPU clock is stopped. The local APIC timer is + stopped. Depending on the processor, additional timers such as + <a class="Xr">x86/tsc(9)</a> may be stopped. Processor caches may be + flushed. Entry and exit latencies are expected to be high; the CPU can no + longer “quickly” respond to bus activity or other + interruptions.</dd> +</dl> +</div> +<p class="Pp">Each state has a latency associated with entry and exit. The + higher the state, the lower the power consumption, and the higher the + potential performance costs.</p> +<p class="Pp">The <code class="Nm">acpicpu</code> driver tries to balance the + latency constraints when choosing the appropriate state. One of the checks + involves bus master activity; if such activity is detected, a lower state is + used. It is known that particularly <a class="Xr">usb(4)</a> may cause high + activity even when not in use. If maximum power savings are desirable, it + may be necessary to use a custom kernel without USB support. And generally: + to save power with C-states, one should avoid polling, both in userland and + in the kernel.</p> +</section> +<section class="Ss"> +<h2 class="Ss" id="P-states"><a class="permalink" href="#P-states">P-states</a></h2> +<p class="Pp">The processor performance states, or P-states, are used to control + the clock frequencies and voltages of a CPU. Underneath the abstractions of + ACPI, P-states are associated with such technologies as + “SpeedStep” (Intel), “PowerNow!” (AMD), and + “PowerSaver” (VIA).</p> +<p class="Pp">The P0-state is always the highest operating frequency supported + by the processor. The number of additional P-states may vary across + processors and vendors. Each higher numbered P-state represents lower clock + frequencies and hence lower power consumption. Note that while + <code class="Nm">acpicpu</code> always uses the exact frequencies + internally, the user-visible values reported by ACPI may be rounded or + approximated by the vendor.</p> +<p class="Pp">Unlike conventional CPU frequency management, ACPI provides + support for Dynamic Voltage and Frequency Scaling (DVFS). Among other + things, this means that the firmware may request the implementation to + dynamically scale the presently supported maximum or minimum clock + frequency. For example, if <a class="Xr">acpiacad(4)</a> is disconnected, + the maximum available frequency may be lowered. By default, the + <span class="Ux">NetBSD</span> implementation may manipulate the frequencies + according to the notifications from the firmware.</p> +</section> +<section class="Ss"> +<h2 class="Ss" id="T-states"><a class="permalink" href="#T-states">T-states</a></h2> +<p class="Pp">Processor T-states, or “throttling states”, can be + used to actively modulate the time a processor is allowed to execute. + Outside the ACPI nomenclature, throttling and T-states may be known as + “on-demand clock modulation” (ODCM).</p> +<p class="Pp">The concept of “duty cycle” is relevant to T-states. + It is generally defined to be a fraction of time that a system is in an + “active” state. The T0-state has always a duty cycle of 100 %, + and thus, comparable to the C0-state, the processor is fully active. Each + additional higher-numbered T-state indicates lower duty cycles. At most + eight T-states may be available, although also T-states use DVFS.</p> +<p class="Pp">The duty cycle does not refer to the actual clock signal, but to + the time period in which the clock signal is allowed to drive the processor + chip. For instance, if a T-state has a duty cycle of 75 %, the CPU runs at + the same clock frequency and uses the same voltage, but 25 % of the time the + CPU is forced to idle. Because of this, the use of T-states may severely + affect system performance.</p> +<p class="Pp">There are two typical situations for throttling: power management + and thermal control. As a technique to save power, T-states are largely an + artifact from the past. There was a short period in the x86 lineage when + P-states were not yet available and throttling was considered as an option + to modulate the processor power consumption. The approach was however + quickly abandoned. In modern x86 systems P-states should be preferred in all + circumstances. It is also more beneficial to move from the C0-state to + deeper C-states than it is to actively force down the duty cycle of a + processor.</p> +<p class="Pp">But T-states have retained their use as a last line of defense + against critical thermal conditions. Many x86 processors include a + catastrophic shutdown detector. When the processor core temperature reaches + this factory defined trip-point, the processor execution is halted without + any software control. Before this fatal condition, it is possible to use + throttling for a short period of time in order to force the temperatures to + lower levels. The thermal control modulation is typically started only when + the system is in the highest-power P-state and a high temperature situation + exists. After the temperatures have returned to non-critical levels, the + modulation ceases.</p> +</section> +<section class="Ss"> +<h2 class="Ss" id="System_Control_Variables"><a class="permalink" href="#System_Control_Variables">System + Control Variables</a></h2> +<p class="Pp">The <code class="Nm">acpicpu</code> driver uses the same + <a class="Xr">sysctl(8)</a> controls for P-states as the ones provided by + <a class="Xr">est(4)</a> and <a class="Xr">powernow(4)</a>. Please note that + future versions of <code class="Nm">acpicpu</code> may however remove these + system control variables without further notice.</p> +<p class="Pp">In addition, the following two variables are available.</p> +<div class="Bd-indent"> +<dl class="Bl-tag"> + <dt id="hw.acpi.cpu.dynamic"><a class="permalink" href="#hw.acpi.cpu.dynamic"><code class="Ic">hw.acpi.cpu.dynamic</code></a></dt> + <dd>A boolean that controls whether the states are allowed to change + dynamically. When enabled, C-, P-, and T-states may all change at runtime, + and <code class="Nm">acpicpu</code> may also take actions based on + requests from the firmware.</dd> + <dt id="hw.acpi.cpu.passive"><a class="permalink" href="#hw.acpi.cpu.passive"><code class="Ic">hw.acpi.cpu.passive</code></a></dt> + <dd>A boolean that enables or disables automatic processor thermal management + via <a class="Xr">acpitz(4)</a>.</dd> +</dl> +</div> +</section> +<section class="Ss"> +<h2 class="Ss" id="Statistics"><a class="permalink" href="#Statistics">Statistics</a></h2> +<p class="Pp">The <code class="Nm">acpicpu</code> driver uses event counters to + track the times a processor has entered a given state. It is possible to + view the statistics by using <a class="Xr">vmstat(1)</a> (with the + <code class="Fl">-e</code> flag).</p> +</section> +</section> +<section class="Sh"> +<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE + ALSO</a></h1> +<p class="Pp"><a class="Xr">acpi(4)</a>, <a class="Xr">acpitz(4)</a>, + <a class="Xr">est(4)</a>, <a class="Xr">odcm(4)</a>, + <a class="Xr">powernow(4)</a>, <a class="Xr">cpu_idle(9)</a></p> +<p class="Pp"><cite class="Rs"><span class="RsA">Etienne Le Sueur</span> and + <span class="RsA">Gernot Heiser</span>, <span class="RsT">Dynamic Voltage + and Frequency Scaling: The Laws of Diminishing Returns</span>, + <a class="RsU" href="http://www.ertos.nicta.com.au/publications/papers/LeSueur_Heiser_10.pdf">http://www.ertos.nicta.com.au/publications/papers/LeSueur_Heiser_10.pdf</a>, + <span class="RsD">October, 2010</span>, <span class="RsO">Proceedings of the + 2010 Workshop on Power Aware Computing and Systems + (HotPower'10)</span>.</cite></p> +<p class="Pp"><cite class="Rs"><span class="RsA">David C. Snowdon</span>, + <span class="RsT">Operating System Directed Power Management</span>, + <i class="RsI">School of Computer Science and Engineering, University of New + South Wales</i>, + <a class="RsU" href="http://ertos.nicta.com.au/publications/papers/Snowdon:phd.pdf">http://ertos.nicta.com.au/publications/papers/Snowdon:phd.pdf</a>, + <span class="RsD">March, 2010</span>, <span class="RsO">PhD + Thesis</span>.</cite></p> +<p class="Pp"><cite class="Rs"><span class="RsA">Microsoft Corporation</span>, + <span class="RsT">Windows Native Processor Performance Control</span>, + <span class="RsN">Version 1.1a</span>, + <a class="RsU" href="http://msdn.microsoft.com/en-us/windows/hardware/gg463343">http://msdn.microsoft.com/en-us/windows/hardware/gg463343</a>, + <span class="RsD">November, 2002</span>.</cite></p> +<p class="Pp"><cite class="Rs"><span class="RsA">Venkatesh Pallipadi</span> and + <span class="RsA">Alexey Starikovskiy</span>, <span class="RsT">The Ondemand + Governor. Past, Present, and Future</span>, <i class="RsI">Intel Open Source + Technology Center</i>, + <a class="RsU" href="https://www.kernel.org/doc/ols/2006/ols2006v2-pages-223-238.pdf">https://www.kernel.org/doc/ols/2006/ols2006v2-pages-223-238.pdf</a>, + <span class="RsD">July, 2006</span>, <span class="RsO">Proceedings of the + Linux Symposium</span>.</cite></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1> +<p class="Pp">The <code class="Nm">acpicpu</code> device driver appeared in + <span class="Ux">NetBSD 6.0</span>.</p> +</section> +<section class="Sh"> +<h1 class="Sh" id="AUTHORS"><a class="permalink" href="#AUTHORS">AUTHORS</a></h1> +<p class="Pp"><span class="An">Jukka Ruohonen</span> + ⟨jruohonen@iki.fi⟩</p> +</section> +<section class="Sh"> +<h1 class="Sh" id="CAVEATS"><a class="permalink" href="#CAVEATS">CAVEATS</a></h1> +<p class="Pp">At least the following caveats can be mentioned.</p> +<ul class="Bl-bullet"> + <li>It is currently only safe to use <code class="Dv">C1</code> on + <span class="Ux">NetBSD</span>. All other C-states are disabled by + default.</li> + <li>Processor thermal control (see <a class="Xr">acpitz(4)</a>) is not yet + supported.</li> + <li>Depending on the processor, changes in C-, P-, and T-states may all skew + timers and counters such as <a class="Xr">x86/tsc(9)</a>. This is neither + handled by <code class="Nm">acpicpu</code> nor by <a class="Xr">est(4)</a> + or <a class="Xr">powernow(4)</a>.</li> + <li>There is currently neither a well-defined, machine-independent API for + processor performance management nor a “governor” for + different policies. It is only possible to control the CPU frequencies + from userland.</li> +</ul> +</section> +</div> +<table class="foot"> + <tr> + <td class="foot-date">August 31, 2018</td> + <td class="foot-os">NetBSD 10.1</td> + </tr> +</table> |