Lines Matching refs:the
13 ``intel_pstate`` is a part of the
14 :doc:`CPU performance scaling subsystem <cpufreq>` in the Linux kernel
15 (``CPUFreq``). It is a scaling driver for the Sandy Bridge and later
18 how ``CPUFreq`` works in general, so this is the time to read :doc:`cpufreq` if
21 For the processors supported by ``intel_pstate``, the P-state concept is broader
22 than just an operating frequency or an operating performance point (see the
24 information about that). For this reason, the representation of P-states used
25 by ``intel_pstate`` internally follows the hardware specification (for details
27 Volume 3: System Programming Guide <SDM_>`_). However, the ``CPUFreq`` core
29 frequencies are involved in the user space interface exposed by it, so
31 (fortunately, that mapping is unambiguous). At the same time, it would not be
32 practical for ``intel_pstate`` to supply the ``CPUFreq`` core with a table of
33 available frequencies due to the possible size of it, so the driver does not do
34 that. Some functionality of the core is limited by that.
36 Since the hardware P-state selection interface used by ``intel_pstate`` is
37 available at the logical CPU level, the driver always works with individual
41 time the corresponding CPU is taken offline and need to be re-initialized when
44 ``intel_pstate`` is not modular, so it cannot be unloaded, which means that the
45 only way to pass early-configuration-time parameters to it is via the kernel
55 ``intel_pstate`` can operate in three different modes: in the active mode with
56 or without hardware-managed P-states support and in the passive mode. Which of
58 on the capabilities of the processor.
63 This is the default operation mode of ``intel_pstate``. If it works in this
64 mode, the ``scaling_driver`` policy attribute in ``sysfs`` for all ``CPUFreq``
65 policies contains the string "intel_pstate".
67 In this mode the driver bypasses the scaling governors layer of ``CPUFreq`` and
69 can be applied to ``CPUFreq`` policies in the same way as generic scaling
70 governors (that is, through the ``scaling_governor`` policy attribute in
74 They are not generic scaling governors, but their names are the same as the
76 do not work in the same way as the generic governors they share the names with.
77 For example, the ``powersave`` P-state selection algorithm provided by
78 ``intel_pstate`` is not a counterpart of the generic ``powersave`` governor
79 (roughly, it corresponds to the ``schedutil`` and ``ondemand`` governors).
81 There are two P-state selection algorithms provided by ``intel_pstate`` in the
83 depends on whether or not the hardware-managed P-states (HWP) feature has been
84 enabled in the processor and possibly on the processor model.
86 Which of the P-state selection algorithms is used by default depends on the
88 Namely, if that option is set, the ``performance`` algorithm will be used by
89 default, and the other one will be used by default if it is not set.
94 If the processor supports the HWP feature, it will be enabled during the
96 to avoid enabling it by passing the ``intel_pstate=no_hwp`` argument to the
97 kernel in the command line.
99 If the HWP feature has been enabled, ``intel_pstate`` relies on the processor to
100 select P-states by itself, but still it can give hints to the processor's
102 selection algorithm has been applied to the given policy (or to the CPU it
105 Even though the P-state selection is carried out by the processor automatically,
106 ``intel_pstate`` registers utilization update callbacks with the CPU scheduler
108 algorithm, but for periodic updates of the current CPU frequency information to
109 be made available from the ``scaling_cur_freq`` policy attribute in ``sysfs``.
114 In this configuration ``intel_pstate`` will write 0 to the processor's
116 Energy-Performance Bias (EPB) knob (otherwise), which means that the processor's
119 This will override the EPP/EPB setting coming from the ``sysfs`` interface
122 Also, in this configuration the range of P-states available to the processor's
123 internal P-state selection logic is always restricted to the upper boundary
124 (that is, the maximum P-state that the driver is allowed to use).
129 In this configuration ``intel_pstate`` will set the processor's
133 set to by the platform firmware). This usually causes the processor's
139 This is the default operation mode for processors that do not support the HWP
140 feature. It also is used by default with the ``intel_pstate=no_hwp`` argument
141 in the kernel command line. However, in this mode ``intel_pstate`` may refuse
142 to work with the given processor if it does not recognize it. [Note that
143 ``intel_pstate`` will never refuse to work with any processor with the HWP
146 In this mode ``intel_pstate`` registers utilization update callbacks with the
148 ``powersave`` or ``performance``, depending on the ``scaling_governor`` policy
150 available from the ``scaling_cur_freq`` policy attribute in ``sysfs`` is
156 Without HWP, this P-state selection algorithm is always the same regardless of
157 the processor model and platform configuration.
159 It selects the maximum P-state it is allowed to use, subject to limits set via
160 ``sysfs``, every time the driver configuration for the given CPU is updated
163 This is the default P-state selection algorithm if the
170 Without HWP, this P-state selection algorithm is similar to the algorithm
171 implemented by the generic ``schedutil`` scaling governor except that the
173 registers of the CPU. It generally selects P-states proportional to the
176 This algorithm is run by the driver's utilization update callback for the
177 given CPU when it is invoked by the CPU scheduler, but not more often than
178 every 10 ms. Like in the ``performance`` case, the hardware configuration
179 is not touched if the new P-state turns out to be the same as the current
182 This is the default P-state selection algorithm if the
189 This mode is used if the ``intel_pstate=passive`` argument is passed to the
190 kernel in the command line (it implies the ``intel_pstate=no_hwp`` setting too).
191 Like in the active mode without HWP support, in this mode ``intel_pstate`` may
192 refuse to work with the given processor if it does not recognize it.
194 If the driver works in this mode, the ``scaling_driver`` policy attribute in
195 ``sysfs`` for all ``CPUFreq`` policies contains the string "intel_cpufreq".
196 Then, the driver behaves like a regular ``CPUFreq`` scaling driver. That is,
197 it is invoked by generic scaling governors when necessary to talk to the
198 hardware in order to change the P-state of a CPU (in particular, the
201 While in this mode, ``intel_pstate`` can be used with all of the (generic)
202 scaling governors listed by the ``scaling_available_governors`` policy attribute
203 in ``sysfs`` (and the P-state selection algorithms described above are not
204 used). Then, it is responsible for the configuration of policy objects
205 corresponding to CPUs and provides the ``CPUFreq`` core (and the scaling
206 governors attached to the policy objects) with accurate information on the
207 maximum and minimum operating frequencies supported by the hardware (including
208 the so-called "turbo" frequency ranges). In other words, in the passive mode
209 the entire range of available P-states is exposed by ``intel_pstate`` to the
210 ``CPUFreq`` core. However, in this mode the driver does not register
211 utilization update callbacks with the CPU scheduler and the ``scaling_cur_freq``
212 information comes from the ``CPUFreq`` core (and is the last frequency selected
213 by the current scaling governor for the given policy).
221 In the majority of cases, the entire range of P-states available to
224 will be referred to as the "turbo threshold" in what follows.
226 The P-states above the turbo threshold are referred to as "turbo P-states" and
227 the whole sub-range of P-states they belong to is referred to as the "turbo
228 range". These names are related to the Turbo Boost technology allowing a
229 multicore processor to opportunistically increase the P-state of one or more
230 cores if there is enough power to do that and if that is not going to cause the
231 thermal envelope of the processor package to be exceeded.
233 Specifically, if software sets the P-state of a CPU core within the turbo range
234 (that is, above the turbo threshold), the processor is permitted to take over
237 different processor generations. Namely, the Sandy Bridge generation of
238 processors will never use any P-states above the last one set by software for
239 the given core, even if it is within the turbo range, whereas all of the later
240 processor generations will take it as a license to use any P-states from the
241 turbo range, even above the one set by software. In other words, on those
242 processors setting any P-state from the turbo range will enable the processor
243 to put the given core into all turbo P-states up to and including the maximum
248 those states indefinitely, because the power distribution within the processor
249 package may change over time or the thermal envelope it was designed for might
252 In turn, the P-states below the turbo threshold generally are sustainable. In
253 fact, if one of them is set by software, the processor is not expected to change
256 the same package at the same time, for example).
258 Some processors allow multiple cores to be in turbo P-states at the same time,
259 but the maximum P-state that can be set for them generally depends on the number
261 cores at the same time usually is lower than the analogous maximum P-state for
262 2 cores, which in turn usually is lower than the maximum turbo P-state that can
263 be set for 1 core. The one-core maximum turbo P-state is thus the maximum
266 The maximum supported turbo P-state, the turbo threshold (the maximum supported
267 non-turbo P-state) and the minimum supported P-state are specific to the
268 processor model and can be determined by reading the processor's model-specific
269 registers (MSRs). Moreover, some processors support the Configurable TDP
270 (Thermal Design Power) feature and, when that feature is enabled, the turbo
271 threshold effectively becomes a configurable value that can be set by the
274 Unlike ``_PSS`` objects in the ACPI tables, ``intel_pstate`` always exposes
275 the entire range of available P-states, including the whole turbo range, to the
276 ``CPUFreq`` core and (in the passive mode) to generic scaling governors. This
281 Moreover, since ``intel_pstate`` always knows what the real turbo threshold is
282 (even if the Configurable TDP feature is enabled in the processor), its
303 * The scaling formula to translate the driver's internal representation
304 of P-states into frequencies and the other way around.
306 Generally, ways to obtain that information are specific to the processor model
307 or family. Although it often is possible to obtain all of it from the processor
312 the driver initialization will fail if the detected processor is not in that
313 list, unless it supports the `HWP feature <Active Mode_>`_. [The interface to
314 obtain all of the information listed above is the same for all of the processors
315 supporting the HWP feature, which is why they all are supported by
326 control its functionality at the system level. They are located in the
329 Some of them are not present if the ``intel_pstate=per_cpu_perf_limits``
330 argument is passed to the kernel in the command line.
333 Maximum P-state the driver is allowed to set in percent of the
334 maximum supported performance level (the highest supported `turbo
337 This attribute will not be exposed if the
338 ``intel_pstate=per_cpu_perf_limits`` argument is present in the kernel
342 Minimum P-state the driver is allowed to set in percent of the
343 maximum supported performance level (the highest supported `turbo
346 This attribute will not be exposed if the
347 ``intel_pstate=per_cpu_perf_limits`` argument is present in the kernel
351 Number of P-states supported by the processor (between 0 and 255
355 The value of this attribute is not affected by the ``no_turbo``
361 Ratio of the `turbo range <turbo_>`_ size to the size of the entire
369 If set (equal to 1), the driver is not allowed to set any turbo P-states
370 (see `Turbo P-states Support`_). If unset (equalt to 0, which is the
371 default), turbo P-states can be set by the driver.
372 [Note that ``intel_pstate`` does not support the general ``boost``
376 This attrubute does not affect the maximum supported frequency value
377 supplied to the ``CPUFreq`` core and exposed via the policy interface,
378 but it affects the maximum possible value of per-policy P-state limits
382 This attribute is only present if ``intel_pstate`` works in the
383 `active mode with the HWP feature enabled <Active Mode With HWP_>`_ in
384 the processor. If set (equal to 1), it causes the minimum P-state limit
386 waiting on I/O is selected to run on a given logical CPU (the purpose
390 is directly set to the highest non-turbo P-state or above it.
395 Operation mode of the driver: "active", "passive" or "off".
398 The driver is functional and in the `active mode
402 The driver is functional and in the `passive mode
407 driver with the ``CPUFreq`` core).
409 This attribute can be written to in order to change the driver's
411 one of the possible values of it and, if successful, the write will
412 cause the driver to switch over to the operation mode represented by
413 that string - or to be unregistered in the "off" case. [Actually,
414 switching over from the active mode to the passive mode or the other
415 way around causes the driver to be unregistered and registered again
416 with a different set of callbacks, so all of its settings (the global
417 as well as the per-policy ones) are then reset to their default
418 values, possibly depending on the target operation mode.]
421 the `HWP feature is enabled in the processor <Active Mode With HWP_>`_,
422 the operation mode of the driver cannot be changed), and if it is not
423 supported in the current configuration, writes to this attribute will
430 :doc:`cpufreq` is special with ``intel_pstate`` as the current scaling driver
431 and it generally depends on the driver's `operation mode <Operation Modes_>`_.
433 First of all, the values of the ``cpuinfo_max_freq``, ``cpuinfo_min_freq`` and
435 multiplier to the internal P-state representation used by ``intel_pstate``.
436 Also, the values of the ``scaling_max_freq`` and ``scaling_min_freq``
437 attributes are capped by the frequency corresponding to the maximum P-state that
438 the driver is allowed to set.
440 If the ``no_turbo`` `global attribute <no_turbo_attr_>`_ is set, the driver is
441 not allowed to use turbo P-states, so the maximum value of ``scaling_max_freq``
442 and ``scaling_min_freq`` is limited to the maximum non-turbo P-state frequency.
445 However, the old values of ``scaling_max_freq`` and ``scaling_min_freq`` will be
449 If ``no_turbo`` is not set, the maximum possible value of ``scaling_max_freq``
450 and ``scaling_min_freq`` corresponds to the maximum supported turbo P-state,
451 which also is the value of ``cpuinfo_max_freq`` in either case.
453 Next, the following policy attributes have special meaning if
454 ``intel_pstate`` works in the `active mode <Active Mode_>`_:
461 use with the given policy.
464 Frequency of the average P-state of the CPU represented by the given
465 policy for the time interval between the last two invocations of the
466 driver's utilization update callback by the CPU scheduler for that CPU.
468 The meaning of these attributes in the `passive mode <Passive Mode_>`_ is the
471 Additionally, the value of the ``scaling_driver`` attribute for ``intel_pstate``
472 depends on the operation mode of the driver. Namely, it is either
473 "intel_pstate" (in the `active mode <Active Mode_>`_) or "intel_cpufreq" (in the
479 ``intel_pstate`` allows P-state limits to be set in two ways: with the help of
480 the ``max_perf_pct`` and ``min_perf_pct`` `global attributes
481 <Global Attributes_>`_ or via the ``scaling_max_freq`` and ``scaling_min_freq``
483 on the following rules, regardless of the current operation mode of the driver:
485 1. All CPUs are affected by the global limits (that is, none of them can be
486 requested to run faster than the global maximum and none of them can be
487 requested to run slower than the global minimum).
495 If the `HWP feature is enabled in the processor <Active Mode With HWP_>`_, the
496 resulting effective values are written into its registers whenever the limits
498 P-states within these limits. Otherwise, the limits are taken into account by
499 scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver
502 Additionally, if the ``intel_pstate=per_cpu_perf_limits`` command line argument
503 is passed to the kernel, ``max_perf_pct`` and ``min_perf_pct`` are not exposed
504 at all and the only way to set the limits is by using the policy attributes.
510 If ``intel_pstate`` works in the `active mode with the HWP feature enabled
511 <Active Mode With HWP_>`_ in the processor, additional attributes are present
513 user space to help ``intel_pstate`` to adjust the processor's internal P-state
515 somewhere between the two extremes:
518 Current value of the energy vs performance hint for the given policy
519 (or the CPU represented by it).
524 List of strings that can be written to the
529 value was set by the platform firmware.
531 Strings written to the ``energy_performance_preference`` attribute are
532 internally translated to integer values written to the processor's
536 [Note that tasks may by migrated from one CPU to another by the scheduler's
539 issues it is better to set the same energy vs performance hint for all CPUs
547 On the majority of systems supported by ``intel_pstate``, the ACPI tables
548 provided by the platform firmware contain ``_PSS`` objects returning information
549 that can be used for CPU performance scaling (refer to the `ACPI specification`_
550 for details on the ``_PSS`` objects and the format of the information returned
553 The information returned by the ACPI ``_PSS`` objects is used by the
555 the ``acpi-cpufreq`` driver uses the same hardware CPU performance scaling
556 interface, but the set of P-states it can use is limited by the ``_PSS``
560 the corresponding CPU which basically is a subset of the P-states range that can
561 be used by ``intel_pstate`` on the same system, with one exception: the whole
562 `turbo range <turbo_>`_ is represented by one item in it (the topmost one). By
563 convention, the frequency returned by ``_PSS`` for that item is greater by 1 MHz
564 than the frequency of the highest non-turbo P-state listed by it, but the
565 corresponding P-state representation (following the hardware specification)
566 returned for it matches the maximum supported turbo P-state (or is the
569 The list of P-states returned by ``_PSS`` is reflected by the table of
570 available frequencies supplied by ``acpi-cpufreq`` to the ``CPUFreq`` core and
571 scaling governors and the minimum and maximum supported frequencies reported by
572 it come from that list as well. In particular, given the special representation
573 of the turbo range described above, this means that the maximum supported
574 frequency reported by ``acpi-cpufreq`` is higher by 1 MHz than the frequency
575 of the highest supported non-turbo P-state listed by ``_PSS`` which, of course,
576 affects decisions made by the scaling governors, except for ``powersave`` and
580 estimated CPU load and maps the load of 100% to the maximum supported frequency
582 the turbo threshold if ``acpi-cpufreq`` is used as the scaling driver, because
583 in that case the turbo range corresponds to a small fraction of the frequency
585 the turbo range for the highest loads and the other loads above 50% that might
589 One more issue related to that may appear on systems supporting the
590 `Configurable TDP feature <turbo_>`_ allowing the platform firmware to set the
591 turbo threshold. Namely, if that is not coordinated with the lists of P-states
593 a turbo P-state in those lists and there may be a problem with avoiding the
595 P-states overall, ``acpi-cpufreq`` simply avoids using the topmost state listed
597 the list returned by it.
599 Apart from the above, ``acpi-cpufreq`` works like ``intel_pstate`` in the
600 `passive mode <Passive Mode_>`_, except that the number of P-states it can set
601 is limited to the ones listed by the ACPI ``_PSS`` objects.
609 of them have to be prepended with the ``intel_pstate=`` prefix.
612 Do not register ``intel_pstate`` as the scaling driver even if the
616 Register ``intel_pstate`` in the `passive mode <Passive Mode_>`_ to
619 This option implies the ``no_hwp`` one described below.
622 Register ``intel_pstate`` as the scaling driver instead of
623 ``acpi-cpufreq`` even if the latter is preferred on the given system.
626 power capping) that rely on the availability of ACPI P-states
631 ``intel_pstate`` and on platforms where the ``pcc-cpufreq`` scaling
635 Do not enable the `hardware-managed P-states (HWP) feature
636 <Active Mode With HWP_>`_ even if it is supported by the processor.
639 Register ``intel_pstate`` as the scaling driver only if the
641 supported by the processor.
646 If the preferred power management profile in the FADT (Fixed ACPI
648 Server", the ACPI ``_PPC`` limits are taken into account by default
663 diagnostics. One of them is the ``cpu_frequency`` trace event generally used
664 by ``CPUFreq``, and the other one is the ``pstate_sample`` trace event specific
666 it works in the `active mode <Active Mode_>`_.
669 their output (if the kernel is generally configured to support event tracing)::
678 If ``intel_pstate`` works in the `passive mode <Passive Mode_>`_, the
679 ``cpu_frequency`` trace event will be triggered either by the ``schedutil``
680 scaling governor (for the policies it is attached to), or by the ``CPUFreq``
681 core (for the policies with other scaling governors).
687 ``intel_pstate``. For example, to check how often the function to set a
688 P-state is called, the ``ftrace`` filter can be set to to