path: root/static/netbsd/man4/acpicpu.4 3.html

<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> &#x2014; <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 &#x201C;quickly&#x201D; 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
    &#x201C;SpeedStep&#x201D; (Intel), &#x201C;PowerNow!&#x201D; (AMD), and
    &#x201C;PowerSaver&#x201D; (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 &#x201C;throttling states&#x201D;, 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
    &#x201C;on-demand clock modulation&#x201D; (ODCM).</p>
<p class="Pp">The concept of &#x201C;duty cycle&#x201D; is relevant to T-states.
    It is generally defined to be a fraction of time that a system is in an
    &#x201C;active&#x201D; 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>
    &#x27E8;jruohonen@iki.fi&#x27E9;</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 &#x201C;governor&#x201D; 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>