Lines Matching refs:idle

17 :doc:`CPU idle time management subsystem <cpuidle>` in the Linux kernel
18 (``CPUIdle``). It is the default CPU idle time management driver for the
27 logical CPU executing it is idle and so it may be possible to put some of the
42 .. _intel-idle-enumeration-of-states:
50 as C-states (in the ACPI terminology) or idle states. The list of meaningful
51 ``MWAIT`` hint values and idle states (i.e. low-power configurations of the
55 In order to create a list of available idle states required by the ``CPUIdle``
56 subsystem (see :ref:`idle-states-representation` in
58 ``intel_idle`` can use two sources of information: static tables of idle states
66 `below <intel-idle-parameters_>`_.]
68 If the ACPI tables are going to be used for building the list of available idle
72 ``CPUIdle`` subsystem expects that the list of idle states supplied by the
75 driver looks for the first ``_CST`` object returning at least one valid idle
76 state description and such that all of the idle states included in its return
80 applicable to all of the other CPUs in the system and the idle state
81 descriptions extracted from it are stored in a preliminary list of idle states
83 configured to ignore the ACPI tables; see `below <intel-idle-parameters_>`_.]
85 Next, the first (index 0) entry in the list of available idle states is
86 initialized to represent a "polling idle state" (a pseudo-idle state in which
88 subsequent (real) idle state entries are populated as follows.
91 (static) table of idle state descriptions for it in the driver. In that case,
92 the "internal" table is the primary source of information on idle states and the
93 information from it is copied to the final list of available idle states. If
94 using the ACPI tables for the enumeration of idle states is not required
95 (depending on the processor model), all of the listed idle state are enabled by
97 governors during CPU idle state selection). Otherwise, some of the listed idle
99 preliminary list of idle states coming from the ACPI tables. In that case user
101 the ``disable`` idle state attribute in ``sysfs`` (see
102 :ref:`idle-states-representation` in
104 the idle states "known" to the driver may not be enabled by default if they have
108 supports ``MWAIT``, the preliminary list of idle states coming from the ACPI
110 ``CPUIdle`` core during driver registration. For each idle state in that list,
112 entry in the final list of idle states. The name of the idle state represented
113 by it (to be returned by the ``name`` idle state attribute in ``sysfs``) is
114 "CX_ACPI", where X is the index of that idle state in the final list (note that
117 C1-type idle states the exit latency value is also used as the target residency
118 (for compatibility with the majority of the "internal" tables of idle states for
119 various processor models recognized by ``intel_idle``) and for the other idle
123 All of the idle states in the final list are enabled by default in this case.
126 .. _intel-idle-initialization:
136 driver, which determines the idle states enumeration method (see
137 `above <intel-idle-enumeration-of-states_>`_), and whether or not the processor
144 `below <intel-idle-parameters_>`_), the idle states information provided by the
148 available idle states is created as explained
149 `above <intel-idle-enumeration-of-states_>`_.
162 .. _intel-idle-parameters:
168 options related to CPU idle time management: ``idle=poll``, ``idle=halt``,
169 and ``idle=nomwait``. If any of them is present in the kernel command line, the
177 The ``max_cstate`` parameter value is the maximum idle state index in the list
178 of idle states supplied to the ``CPUIdle`` core during the registration of the
179 driver. It is also the maximum number of regular (non-polling) idle states that
180 can be used by ``intel_idle``, so the enumeration of idle states is terminated
181 after finding that number of usable idle states (the other idle states that
184 ``intel_idle`` from exposing idle states that are regarded as "too deep" for
187 be desirable. In practice, it is only really necessary to do that if the idle
190 QoS) feature can be used to prevent ``CPUIdle`` from touching those idle states
202 list of idle states to be disabled by default in the form of a bitmask.
205 the indices of idle states to be disabled by default (as reflected by the names
206 of the corresponding idle state directories in ``sysfs``, :file:`state0`,
208 idle state; see :ref:`idle-states-representation` in
211 For example, if ``states_off`` is equal to 3, the driver will disable idle
212 states 0 and 1 by default, and if it is equal to 8, idle state 3 will be
213 disabled by default and so on (bit positions beyond the maximum idle state index
216 The idle states disabled this way can be enabled (on a per-CPU basis) from user
220 .. _intel-idle-core-and-package-idle-states:
226 least) two levels of idle states (or C-states). One level, referred to as
234 to the ``C1`` idle state), but the majority of them give it a license to put
238 ``MWAIT`` hint value representing the ``C3`` idle state allows the processor to
242 representing a deeper idle state), and in addition to that (in the majority of
257 tables of idle states in ``intel_idle`` reflect the properties of package
260 ``intel_idle`` described `above <intel-idle-parameters_>`_ must be used to
261 restrict the range of permissible idle states to the ones with core-level only