Lines Matching +full:wakeup +full:- +full:latency +full:- +full:us

1 .. SPDX-License-Identifier: GPL-2.0
24 Documentation/admin-guide/pm/cpuidle.rst if you have not done that yet.]
28 processor's functional blocks into low-power states.  That instruction takes two
38 only way to pass early-configuration-time parameters to it is via the kernel
55 	C-state requests from the OS (e.g., C6 requests) to C1. The idea is that
56 	firmware monitors CPU wake-up rate, and if it is higher than a
57 	platform-specific threshold, the firmware demotes deep C-state requests
59 	wake-ups per second, and it keeps the CPU in C1. When the CPU stays in
63 .. _intel-idle-enumeration-of-states:
71 as C-states (in the ACPI terminology) or idle states.  The list of meaningful
72 ``MWAIT`` hint values and idle states (i.e. low-power configurations of the
77 subsystem (see :ref:`idle-states-representation` in
78 Documentation/admin-guide/pm/cpuidle.rst),
87 `below <intel-idle-parameters_>`_.]
104 configured to ignore the ACPI tables; see `below <intel-idle-parameters_>`_.]
107 initialized to represent a "polling idle state" (a pseudo-idle state in which
121 space still can enable them later (on a per-CPU basis) with the help of
123 :ref:`idle-states-representation` in
124 Documentation/admin-guide/pm/cpuidle.rst).  This basically means that
132 the description, ``MWAIT`` hint and exit latency are copied to the corresponding
137 its target residency is based on the exit latency value.  Specifically, for
138 C1-type idle states the exit latency value is also used as the target residency
141 state types (C2 and C3) the target residency value is 3 times the exit latency
142 (again, that is because it reflects the target residency to exit latency ratio
147 .. _intel-idle-initialization:
158 `above <intel-idle-enumeration-of-states_>`_), and whether or not the processor
165 `below <intel-idle-parameters_>`_), the idle states information provided by the
170 `above <intel-idle-enumeration-of-states_>`_.
179 optionally performs some CPU-specific initialization actions that may be
183 .. _intel-idle-parameters:
200 driver.  It is also the maximum number of regular (non-polling) idle states that
212 even if they have been enumerated (see :ref:`cpu-pm-qos` in
213 Documentation/admin-guide/pm/cpuidle.rst).
221 ``no_acpi`` - Do not use ACPI at all.  Only native mode is available, no
224 ``use_acpi`` - No-op in ACPI mode, the driver will consult ACPI tables for
225 C-states on/off status in native mode.
227 ``no_native`` - Work only in ACPI mode, no native mode available (ignore
237 idle state; see :ref:`idle-states-representation` in
238 Documentation/admin-guide/pm/cpuidle.rst).
245 The idle states disabled this way can be enabled (on a per-CPU basis) from user
260 help performance of a sibling CPU at the expense of a slightly higher wakeup
261 latency for the idle CPU.
264 .. _intel-idle-core-and-package-idle-states:
270 least) two levels of idle states (or C-states).  One level, referred to as
271 "core C-states", covers individual cores in the processor, whereas the other
272 level, referred to as "package C-states", covers the entire processor package
276 Some of the ``MWAIT`` hint values allow the processor to use core C-states only
280 with the given hint value) into a specific core C-state and then (if possible)
281 to enter a specific package C-state at the deeper level.  For example, the
283 put the target core into the low-power state referred to as "core ``C3``" (or
288 including some non-CPU components such as a GPU or a memory controller) into the
289 low-power state referred to as "package ``C3``" (or ``PC3``), which happens if
292 be required to be in a certain GPU-specific low-power state for ``PC3`` to be
295 As a rule, there is no simple way to make the processor use core C-states only
296 if the conditions for entering the corresponding package C-states are met, so
297 the logical CPU executing ``MWAIT`` with a hint value that is not core-level
299 enter a package C-state.  [That is why the exit latency and target residency
302 C-states.]  If using package C-states is not desirable at all, either
303 :ref:`PM QoS <cpu-pm-qos>` or the ``max_cstate`` module parameter of
304 ``intel_idle`` described `above <intel-idle-parameters_>`_ must be used to
305 restrict the range of permissible idle states to the ones with core-level only
312 .. [1] *Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2B*,
313 …https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-softwar…