Lines Matching full:the
16 ``intel_pstate`` is a part of the
17 :doc:`CPU performance scaling subsystem <cpufreq>` in the Linux kernel
18 (``CPUFreq``). It is a scaling driver for the Sandy Bridge and later
21 how ``CPUFreq`` works in general, so this is the time to read
24 For the processors supported by ``intel_pstate``, the P-state concept is broader
25 than just an operating frequency or an operating performance point (see the
27 information about that). For this reason, the representation of P-states used
28 by ``intel_pstate`` internally follows the hardware specification (for details
29 refer to Intel Software Developer’s Manual [2]_). However, the ``CPUFreq`` core
31 frequencies are involved in the user space interface exposed by it, so
33 (fortunately, that mapping is unambiguous). At the same time, it would not be
34 practical for ``intel_pstate`` to supply the ``CPUFreq`` core with a table of
35 available frequencies due to the possible size of it, so the driver does not do
36 that. Some functionality of the core is limited by that.
38 Since the hardware P-state selection interface used by ``intel_pstate`` is
39 available at the logical CPU level, the driver always works with individual
43 time the corresponding CPU is taken offline and need to be re-initialized when
46 ``intel_pstate`` is not modular, so it cannot be unloaded, which means that the
47 only way to pass early-configuration-time parameters to it is via the kernel
57 ``intel_pstate`` can operate in two different modes, active or passive. In the
59 allows the hardware to do performance scaling by itself, while in the passive
62 depends on what kernel command line options are used and on the capabilities of
63 the processor.
68 This is the default operation mode of ``intel_pstate`` for processors with
69 hardware-managed P-states (HWP) support. If it works in this mode, the
71 contains the string "intel_pstate".
73 In this mode the driver bypasses the scaling governors layer of ``CPUFreq`` and
75 can be applied to ``CPUFreq`` policies in the same way as generic scaling
76 governors (that is, through the ``scaling_governor`` policy attribute in
80 They are not generic scaling governors, but their names are the same as the
82 do not work in the same way as the generic governors they share the names with.
83 For example, the ``powersave`` P-state selection algorithm provided by
84 ``intel_pstate`` is not a counterpart of the generic ``powersave`` governor
85 (roughly, it corresponds to the ``schedutil`` and ``ondemand`` governors).
87 There are two P-state selection algorithms provided by ``intel_pstate`` in the
88 active mode: ``powersave`` and ``performance``. The way they both operate
89 depends on whether or not the hardware-managed P-states (HWP) feature has been
90 enabled in the processor and possibly on the processor model.
92 Which of the P-state selection algorithms is used by default depends on the
94 Namely, if that option is set, the ``performance`` algorithm will be used by
95 default, and the other one will be used by default if it is not set.
100 If the processor supports the HWP feature, it will be enabled during the
102 to avoid enabling it by passing the ``intel_pstate=no_hwp`` argument to the
103 kernel in the command line.
105 If the HWP feature has been enabled, ``intel_pstate`` relies on the processor to
106 select P-states by itself, but still it can give hints to the processor's
108 selection algorithm has been applied to the given policy (or to the CPU it
111 Even though the P-state selection is carried out by the processor automatically,
112 ``intel_pstate`` registers utilization update callbacks with the CPU scheduler
114 algorithm, but for periodic updates of the current CPU frequency information to
115 be made available from the ``scaling_cur_freq`` policy attribute in ``sysfs``.
120 In this configuration ``intel_pstate`` will write 0 to the processor's
122 Energy-Performance Bias (EPB) knob (otherwise), which means that the processor's
125 This will override the EPP/EPB setting coming from the ``sysfs`` interface
127 the EPP/EPB to a value different from 0 ("performance") via ``sysfs`` in this
130 Also, in this configuration the range of P-states available to the processor's
131 internal P-state selection logic is always restricted to the upper boundary
132 (that is, the maximum P-state that the driver is allowed to use).
137 In this configuration ``intel_pstate`` will set the processor's
141 set to by the platform firmware). This usually causes the processor's
147 This operation mode is optional for processors that do not support the HWP
148 feature or when the ``intel_pstate=no_hwp`` argument is passed to the kernel in
149 the command line. The active mode is used in those cases if the
150 ``intel_pstate=active`` argument is passed to the kernel in the command line.
153 any processor with the HWP feature enabled.]
155 In this mode ``intel_pstate`` registers utilization update callbacks with the
157 ``powersave`` or ``performance``, depending on the ``scaling_governor`` policy
158 setting in ``sysfs``. The current CPU frequency information to be made
159 available from the ``scaling_cur_freq`` policy attribute in ``sysfs`` is
165 Without HWP, this P-state selection algorithm is always the same regardless of
166 the processor model and platform configuration.
168 It selects the maximum P-state it is allowed to use, subject to limits set via
169 ``sysfs``, every time the driver configuration for the given CPU is updated
172 This is the default P-state selection algorithm if the
179 Without HWP, this P-state selection algorithm is similar to the algorithm
180 implemented by the generic ``schedutil`` scaling governor except that the
182 registers of the CPU. It generally selects P-states proportional to the
185 This algorithm is run by the driver's utilization update callback for the
186 given CPU when it is invoked by the CPU scheduler, but not more often than
187 every 10 ms. Like in the ``performance`` case, the hardware configuration
188 is not touched if the new P-state turns out to be the same as the current
191 This is the default P-state selection algorithm if the
198 This is the default operation mode of ``intel_pstate`` for processors without
199 hardware-managed P-states (HWP) support. It is always used if the
200 ``intel_pstate=passive`` argument is passed to the kernel in the command line
201 regardless of whether or not the given processor supports HWP. [Note that the
202 ``intel_pstate=no_hwp`` setting causes the driver to start in the passive mode
203 if it is not combined with ``intel_pstate=active``.] Like in the active mode
206 through the kernel command line.
208 If the driver works in this mode, the ``scaling_driver`` policy attribute in
209 ``sysfs`` for all ``CPUFreq`` policies contains the string "intel_cpufreq".
210 Then, the driver behaves like a regular ``CPUFreq`` scaling driver. That is,
211 it is invoked by generic scaling governors when necessary to talk to the
212 hardware in order to change the P-state of a CPU (in particular, the
215 While in this mode, ``intel_pstate`` can be used with all of the (generic)
216 scaling governors listed by the ``scaling_available_governors`` policy attribute
217 in ``sysfs`` (and the P-state selection algorithms described above are not
218 used). Then, it is responsible for the configuration of policy objects
219 corresponding to CPUs and provides the ``CPUFreq`` core (and the scaling
220 governors attached to the policy objects) with accurate information on the
221 maximum and minimum operating frequencies supported by the hardware (including
222 the so-called "turbo" frequency ranges). In other words, in the passive mode
223 the entire range of available P-states is exposed by ``intel_pstate`` to the
224 ``CPUFreq`` core. However, in this mode the driver does not register
225 utilization update callbacks with the CPU scheduler and the ``scaling_cur_freq``
226 information comes from the ``CPUFreq`` core (and is the last frequency selected
227 by the current scaling governor for the given policy).
235 In the majority of cases, the entire range of P-states available to
238 will be referred to as the "turbo threshold" in what follows.
240 The P-states above the turbo threshold are referred to as "turbo P-states" and
241 the whole sub-range of P-states they belong to is referred to as the "turbo
242 range". These names are related to the Turbo Boost technology allowing a
243 multicore processor to opportunistically increase the P-state of one or more
244 cores if there is enough power to do that and if that is not going to cause the
245 thermal envelope of the processor package to be exceeded.
247 Specifically, if software sets the P-state of a CPU core within the turbo range
248 (that is, above the turbo threshold), the processor is permitted to take over
251 different processor generations. Namely, the Sandy Bridge generation of
252 processors will never use any P-states above the last one set by software for
253 the given core, even if it is within the turbo range, whereas all of the later
254 processor generations will take it as a license to use any P-states from the
255 turbo range, even above the one set by software. In other words, on those
256 processors setting any P-state from the turbo range will enable the processor
257 to put the given core into all turbo P-states up to and including the maximum
262 those states indefinitely, because the power distribution within the processor
263 package may change over time or the thermal envelope it was designed for might
266 In turn, the P-states below the turbo threshold generally are sustainable. In
267 fact, if one of them is set by software, the processor is not expected to change
270 the same package at the same time, for example).
272 Some processors allow multiple cores to be in turbo P-states at the same time,
273 but the maximum P-state that can be set for them generally depends on the number
274 of cores running concurrently. The maximum turbo P-state that can be set for 3
275 cores at the same time usually is lower than the analogous maximum P-state for
276 2 cores, which in turn usually is lower than the maximum turbo P-state that can
277 be set for 1 core. The one-core maximum turbo P-state is thus the maximum
280 The maximum supported turbo P-state, the turbo threshold (the maximum supported
281 non-turbo P-state) and the minimum supported P-state are specific to the
282 processor model and can be determined by reading the processor's model-specific
283 registers (MSRs). Moreover, some processors support the Configurable TDP
284 (Thermal Design Power) feature and, when that feature is enabled, the turbo
285 threshold effectively becomes a configurable value that can be set by the
288 Unlike ``_PSS`` objects in the ACPI tables, ``intel_pstate`` always exposes
289 the entire range of available P-states, including the whole turbo range, to the
290 ``CPUFreq`` core and (in the passive mode) to generic scaling governors. This
295 Moreover, since ``intel_pstate`` always knows what the real turbo threshold is
296 (even if the Configurable TDP feature is enabled in the processor), its
308 * The minimum supported P-state.
310 * The maximum supported `non-turbo P-state <turbo_>`_.
314 * The maximum supported `one-core turbo P-state <turbo_>`_ (if turbo P-states
317 * The scaling formula to translate the driver's internal representation
318 of P-states into frequencies and the other way around.
320 Generally, ways to obtain that information are specific to the processor model
321 or family. Although it often is possible to obtain all of it from the processor
326 the driver initialization will fail if the detected processor is not in that
327 list, unless it supports the HWP feature. [The interface to obtain all of the
328 information listed above is the same for all of the processors supporting the
339 control its functionality at the system level. They are located in the
342 Some of them are not present if the ``intel_pstate=per_cpu_perf_limits``
343 argument is passed to the kernel in the command line.
346 Maximum P-state the driver is allowed to set in percent of the
347 maximum supported performance level (the highest supported `turbo
350 This attribute will not be exposed if the
351 ``intel_pstate=per_cpu_perf_limits`` argument is present in the kernel
355 Minimum P-state the driver is allowed to set in percent of the
356 maximum supported performance level (the highest supported `turbo
359 This attribute will not be exposed if the
360 ``intel_pstate=per_cpu_perf_limits`` argument is present in the kernel
364 Number of P-states supported by the processor (between 0 and 255
368 This attribute is present only if the value exposed by it is the same
369 for all of the CPUs in the system.
371 The value of this attribute is not affected by the ``no_turbo``
377 Ratio of the `turbo range <turbo_>`_ size to the size of the entire
380 This attribute is present only if the value exposed by it is the same
381 for all of the CPUs in the system.
388 If set (equal to 1), the driver is not allowed to set any turbo P-states
389 (see `Turbo P-states Support`_). If unset (equal to 0, which is the
390 default), turbo P-states can be set by the driver.
391 [Note that ``intel_pstate`` does not support the general ``boost``
395 This attribute does not affect the maximum supported frequency value
396 supplied to the ``CPUFreq`` core and exposed via the policy interface,
397 but it affects the maximum possible value of per-policy P-state limits
401 This attribute is only present if ``intel_pstate`` works in the
402 `active mode with the HWP feature enabled <Active Mode With HWP_>`_ in
403 the processor. If set (equal to 1), it causes the minimum P-state limit
405 waiting on I/O is selected to run on a given logical CPU (the purpose
409 is directly set to the highest non-turbo P-state or above it.
414 Operation mode of the driver: "active", "passive" or "off".
417 The driver is functional and in the `active mode
421 The driver is functional and in the `passive mode
425 The driver is not functional (it is not registered as a scaling
426 driver with the ``CPUFreq`` core).
428 This attribute can be written to in order to change the driver's
429 operation mode or to unregister it. The string written to it must be
430 one of the possible values of it and, if successful, the write will
431 cause the driver to switch over to the operation mode represented by
432 that string - or to be unregistered in the "off" case. [Actually,
433 switching over from the active mode to the passive mode or the other
434 way around causes the driver to be unregistered and registered again
435 with a different set of callbacks, so all of its settings (the global
436 as well as the per-policy ones) are then reset to their default
437 values, possibly depending on the target operation mode.]
440 This attribute is only present on platforms with CPUs matching the Kaby
444 frequency with or without the HWP feature. With HWP enabled, the
445 optimizations are done only in the turbo frequency range. Without it,
446 they are done in the entire available frequency range. Setting this
447 attribute to "1" enables the energy-efficiency optimizations and setting
453 The interpretation of some ``CPUFreq`` policy attributes described in
455 as the current scaling driver and it generally depends on the driver's
458 First of all, the values of the ``cpuinfo_max_freq``, ``cpuinfo_min_freq`` and
460 multiplier to the internal P-state representation used by ``intel_pstate``.
461 Also, the values of the ``scaling_max_freq`` and ``scaling_min_freq``
462 attributes are capped by the frequency corresponding to the maximum P-state that
463 the driver is allowed to set.
465 If the ``no_turbo`` `global attribute <no_turbo_attr_>`_ is set, the driver is
466 not allowed to use turbo P-states, so the maximum value of ``scaling_max_freq``
467 and ``scaling_min_freq`` is limited to the maximum non-turbo P-state frequency.
470 However, the old values of ``scaling_max_freq`` and ``scaling_min_freq`` will be
474 If ``no_turbo`` is not set, the maximum possible value of ``scaling_max_freq``
475 and ``scaling_min_freq`` corresponds to the maximum supported turbo P-state,
476 which also is the value of ``cpuinfo_max_freq`` in either case.
478 Next, the following policy attributes have special meaning if
479 ``intel_pstate`` works in the `active mode <Active Mode_>`_:
486 use with the given policy.
489 Frequency of the average P-state of the CPU represented by the given
490 policy for the time interval between the last two invocations of the
491 driver's utilization update callback by the CPU scheduler for that CPU.
493 One more policy attribute is present if the HWP feature is enabled in the
497 Shows the base frequency of the CPU. Any frequency above this will be
498 in the turbo frequency range.
500 The meaning of these attributes in the `passive mode <Passive Mode_>`_ is the
503 Additionally, the value of the ``scaling_driver`` attribute for ``intel_pstate``
504 depends on the operation mode of the driver. Namely, it is either
505 "intel_pstate" (in the `active mode <Active Mode_>`_) or "intel_cpufreq" (in the
511 ``intel_pstate`` allows P-state limits to be set in two ways: with the help of
512 the ``max_perf_pct`` and ``min_perf_pct`` `global attributes
513 <Global Attributes_>`_ or via the ``scaling_max_freq`` and ``scaling_min_freq``
514 ``CPUFreq`` policy attributes. The coordination between those limits is based
515 on the following rules, regardless of the current operation mode of the driver:
517 1. All CPUs are affected by the global limits (that is, none of them can be
518 requested to run faster than the global maximum and none of them can be
519 requested to run slower than the global minimum).
523 cannot be requested to run slower than its own per-policy minimum). The
524 effective performance depends on whether the platform supports per core
526 from other CPUs. When platform doesn't support per core P-states, the
527 effective performance can be more than the policy limits set on a CPU, if
529 core P-states support, when hyper-threading is enabled, if the sibling CPU
530 is requesting higher performance, the other siblings will get higher
533 3. The global and per-policy limits can be set independently.
535 In the `active mode with the HWP feature enabled <Active Mode With HWP_>`_, the
536 resulting effective values are written into hardware registers whenever the
538 set P-states within these limits. Otherwise, the limits are taken into account
539 by scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver
542 Additionally, if the ``intel_pstate=per_cpu_perf_limits`` command line argument
543 is passed to the kernel, ``max_perf_pct`` and ``min_perf_pct`` are not exposed
544 at all and the only way to set the limits is by using the policy attributes.
550 If the hardware-managed P-states (HWP) is enabled in the processor, additional
551 attributes, intended to allow user space to help ``intel_pstate`` to adjust the
553 energy-efficiency, or somewhere between the two extremes, are present in every
557 Current value of the energy vs performance hint for the given policy
558 (or the CPU represented by it).
560 The hint can be changed by writing to this attribute.
563 List of strings that can be written to the
568 value was set by the platform firmware.
570 Strings written to the ``energy_performance_preference`` attribute are
571 internally translated to integer values written to the processor's
574 integer value between 0 to 255, if the EPP feature is present. If the EPP
576 supported. In this case, user can use the
579 [Note that tasks may by migrated from one CPU to another by the scheduler's
582 issues it is better to set the same energy vs performance hint for all CPUs
590 On the majority of systems supported by ``intel_pstate``, the ACPI tables
591 provided by the platform firmware contain ``_PSS`` objects returning information
592 that can be used for CPU performance scaling (refer to the ACPI specification
593 [3]_ for details on the ``_PSS`` objects and the format of the information
596 The information returned by the ACPI ``_PSS`` objects is used by the
598 the ``acpi-cpufreq`` driver uses the same hardware CPU performance scaling
599 interface, but the set of P-states it can use is limited by the ``_PSS``
603 the corresponding CPU which basically is a subset of the P-states range that can
604 be used by ``intel_pstate`` on the same system, with one exception: the whole
605 `turbo range <turbo_>`_ is represented by one item in it (the topmost one). By
606 convention, the frequency returned by ``_PSS`` for that item is greater by 1 MHz
607 than the frequency of the highest non-turbo P-state listed by it, but the
608 corresponding P-state representation (following the hardware specification)
609 returned for it matches the maximum supported turbo P-state (or is the
612 The list of P-states returned by ``_PSS`` is reflected by the table of
613 available frequencies supplied by ``acpi-cpufreq`` to the ``CPUFreq`` core and
614 scaling governors and the minimum and maximum supported frequencies reported by
615 it come from that list as well. In particular, given the special representation
616 of the turbo range described above, this means that the maximum supported
617 frequency reported by ``acpi-cpufreq`` is higher by 1 MHz than the frequency
618 of the highest supported non-turbo P-state listed by ``_PSS`` which, of course,
619 affects decisions made by the scaling governors, except for ``powersave`` and
623 estimated CPU load and maps the load of 100% to the maximum supported frequency
625 the turbo threshold if ``acpi-cpufreq`` is used as the scaling driver, because
626 in that case the turbo range corresponds to a small fraction of the frequency
628 the turbo range for the highest loads and the other loads above 50% that might
632 One more issue related to that may appear on systems supporting the
633 `Configurable TDP feature <turbo_>`_ allowing the platform firmware to set the
634 turbo threshold. Namely, if that is not coordinated with the lists of P-states
636 a turbo P-state in those lists and there may be a problem with avoiding the
638 P-states overall, ``acpi-cpufreq`` simply avoids using the topmost state listed
640 the list returned by it.
642 Apart from the above, ``acpi-cpufreq`` works like ``intel_pstate`` in the
643 `passive mode <Passive Mode_>`_, except that the number of P-states it can set
644 is limited to the ones listed by the ACPI ``_PSS`` objects.
652 of them have to be prepended with the ``intel_pstate=`` prefix.
655 Do not register ``intel_pstate`` as the scaling driver even if the
659 Register ``intel_pstate`` in the `active mode <Active Mode_>`_ to start
663 Register ``intel_pstate`` in the `passive mode <Passive Mode_>`_ to
667 Register ``intel_pstate`` as the scaling driver instead of
668 ``acpi-cpufreq`` even if the latter is preferred on the given system.
671 power capping) that rely on the availability of ACPI P-states
676 ``intel_pstate`` and on platforms where the ``pcc-cpufreq`` scaling
680 Do not enable the hardware-managed P-states (HWP) feature even if it is
681 supported by the processor.
684 Register ``intel_pstate`` as the scaling driver only if the
685 hardware-managed P-states (HWP) feature is supported by the processor.
690 If the preferred power management profile in the FADT (Fixed ACPI
692 Server", the ACPI ``_PPC`` limits are taken into account by default
707 diagnostics. One of them is the ``cpu_frequency`` trace event generally used
708 by ``CPUFreq``, and the other one is the ``pstate_sample`` trace event specific
710 it works in the `active mode <Active Mode_>`_.
712 The following sequence of shell commands can be used to enable them and see
713 their output (if the kernel is generally configured to support event tracing)::
722 If ``intel_pstate`` works in the `passive mode <Passive Mode_>`_, the
723 ``cpu_frequency`` trace event will be triggered either by the ``schedutil``
724 scaling governor (for the policies it is attached to), or by the ``CPUFreq``
725 core (for the policies with other scaling governors).
730 The ``ftrace`` interface can be used for low-level diagnostics of
731 ``intel_pstate``. For example, to check how often the function to set a
732 P-state is called, the ``ftrace`` filter can be set to
763 .. [1] Kristen Accardi, *Balancing Power and Performance in the Linux Kernel*,