1 .. SPDX-License-Identifier: GPL-2.0
2 .. include:: <isonum.txt>
4 ===============================================
5 ``intel_pstate`` CPU Performance Scaling Driver
6 ===============================================
8 :Copyright: |copy| 2017 Intel Corporation
10 :Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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
19 generations of Intel processors. Note, however, that some of those processors
20 may not be supported. [To understand ``intel_pstate`` it is necessary to know
21 how ``CPUFreq`` works in general, so this is the time to read
22 Documentation/admin-guide/pm/cpufreq.rst if you have not done that yet.]
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
26 LinuxCon Europe 2015 presentation by Kristen Accardi [1]_ for more
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
30 uses frequencies for identifying operating performance points of CPUs and
31 frequencies are involved in the user space interface exposed by it, so
32 ``intel_pstate`` maps its internal representation of P-states to frequencies too
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
40 CPUs. Consequently, if ``intel_pstate`` is in use, every ``CPUFreq`` policy
41 object corresponds to one logical CPU and ``CPUFreq`` policies are effectively
42 equivalent to CPUs. In particular, this means that they become "inactive" every
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
48 command line. However, its configuration can be adjusted via ``sysfs`` to a
49 great extent. In some configurations it even is possible to unregister it via
50 ``sysfs`` which allows another ``CPUFreq`` scaling driver to be loaded and
51 registered (see `below <status_attr_>`_).
57 ``intel_pstate`` can operate in two different modes, active or passive. In the
58 active mode, it uses its own internal performance scaling governor algorithm or
59 allows the hardware to do performance scaling by itself, while in the passive
60 mode it responds to requests made by a generic ``CPUFreq`` governor implementing
61 a certain performance scaling algorithm. Which of them will be in effect
62 depends on what kernel command line options are used and on the capabilities of
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
70 ``scaling_driver`` policy attribute in ``sysfs`` for all ``CPUFreq`` policies
71 contains the string "intel_pstate".
73 In this mode the driver bypasses the scaling governors layer of ``CPUFreq`` and
74 provides its own scaling algorithms for P-state selection. Those algorithms
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
77 ``sysfs``). [Note that different P-state selection algorithms may be chosen for
78 different policies, but that is not recommended.]
80 They are not generic scaling governors, but their names are the same as the
81 names of some of those governors. Moreover, confusingly enough, they generally
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
93 :c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option.
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
101 processor initialization and cannot be disabled after that. It is possible
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
107 internal P-state selection logic. What those hints are depends on which P-state
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
113 in this mode. However, they are not used for running a P-state selection
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``.
117 HWP + ``performance``
118 .....................
120 In this configuration ``intel_pstate`` will write 0 to the processor's
121 Energy-Performance Preference (EPP) knob (if supported) or its
122 Energy-Performance Bias (EPB) knob (otherwise), which means that the processor's
123 internal P-state selection logic is expected to focus entirely on performance.
125 This will override the EPP/EPB setting coming from the ``sysfs`` interface
126 (see `Energy vs Performance Hints`_ below). Moreover, any attempts to change
127 the EPP/EPB to a value different from 0 ("performance") via ``sysfs`` in this
128 configuration will be rejected.
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
138 Energy-Performance Preference (EPP) knob (if supported) or its
139 Energy-Performance Bias (EPB) knob (otherwise) to whatever value it was
140 previously set to via ``sysfs`` (or whatever default value it was
141 set to by the platform firmware). This usually causes the processor's
142 internal P-state selection logic to be less performance-focused.
144 Active Mode Without HWP
145 ~~~~~~~~~~~~~~~~~~~~~~~
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.
151 In this mode ``intel_pstate`` may refuse to work with processors that are not
152 recognized by it. [Note that ``intel_pstate`` will never refuse to work with
153 any processor with the HWP feature enabled.]
155 In this mode ``intel_pstate`` registers utilization update callbacks with the
156 CPU scheduler in order to run a P-state selection algorithm, either
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
160 periodically updated by those utilization update callbacks too.
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
170 (e.g. via ``sysfs``).
172 This is the default P-state selection algorithm if the
173 :c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option
179 Without HWP, this P-state selection algorithm is similar to the algorithm
180 implemented by the generic ``schedutil`` scaling governor except that the
181 utilization metric used by it is based on numbers coming from feedback
182 registers of the CPU. It generally selects P-states proportional to the
183 current CPU utilization.
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
192 :c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option
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
204 without HWP support, in this mode ``intel_pstate`` may refuse to work with
205 processors that are not recognized by it if HWP is prevented from being enabled
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
213 ``schedutil`` governor can invoke it directly from scheduler context).
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).
232 Turbo P-states Support
233 ======================
235 In the majority of cases, the entire range of P-states available to
236 ``intel_pstate`` can be divided into two sub-ranges that correspond to
237 different types of processor behavior, above and below a boundary that
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
249 performance scaling control for that core and put it into turbo P-states of its
250 choice going forward. However, that permission is interpreted differently by
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
258 supported one as it sees fit.
260 One important property of turbo P-states is that they are not sustainable. More
261 precisely, there is no guarantee that any CPUs will be able to stay in any of
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
264 be exceeded if a turbo P-state was used for too long.
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
268 it to a lower one unless in a thermal stress or a power limit violation
269 situation (a higher P-state may still be used if it is set for another CPU in
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
278 supported one overall.
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
291 generally causes turbo P-states to be set more often when ``intel_pstate`` is
292 used relative to ACPI-based CPU performance scaling (see `below <acpi-cpufreq_>`_
293 for more information).
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
297 ``no_turbo`` attribute in ``sysfs`` (described `below <no_turbo_attr_>`_) should
298 work as expected in all cases (that is, if set to disable turbo P-states, it
299 always should prevent ``intel_pstate`` from using them).
305 To handle a given processor ``intel_pstate`` requires a number of different
306 pieces of information on it to be known, including:
308 * The minimum supported P-state.
310 * The maximum supported `non-turbo P-state <turbo_>`_.
312 * Whether or not turbo P-states are supported at all.
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
322 itself (using model-specific registers), there are cases in which hardware
323 manuals need to be consulted to get to it too.
325 For this reason, there is a list of supported processors in ``intel_pstate`` and
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
329 HWP feature, which is why ``intel_pstate`` works with all of them.]
332 Support for Hybrid Processors
333 =============================
335 Some processors supported by ``intel_pstate`` contain two or more types of CPU
336 cores differing by the maximum turbo P-state, performance vs power characteristics,
337 cache sizes, and possibly other properties. They are commonly referred to as
338 hybrid processors. To support them, ``intel_pstate`` requires HWP to be enabled
339 and it assumes the HWP performance units to be the same for all CPUs in the
340 system, so a given HWP performance level always represents approximately the
341 same physical performance regardless of the core (CPU) type.
343 Hybrid Processors with SMT
344 --------------------------
346 On systems where SMT (Simultaneous Multithreading), also referred to as
347 HyperThreading (HT) in the context of Intel processors, is enabled on at least
348 one core, ``intel_pstate`` assigns performance-based priorities to CPUs. Namely,
349 the priority of a given CPU reflects its highest HWP performance level which
350 causes the CPU scheduler to generally prefer more performant CPUs, so the less
351 performant CPUs are used when the other ones are fully loaded. However, SMT
352 siblings (that is, logical CPUs sharing one physical core) are treated in a
353 special way such that if one of them is in use, the effective priority of the
354 other ones is lowered below the priorities of the CPUs located in the other
357 This approach maximizes performance in the majority of cases, but unfortunately
358 it also leads to excessive energy usage in some important scenarios, like video
359 playback, which is not generally desirable. While there is no other viable
360 choice with SMT enabled because the effective capacity and utilization of SMT
361 siblings are hard to determine, hybrid processors without SMT can be handled in
362 more energy-efficient ways.
366 Capacity-Aware Scheduling Support
367 ---------------------------------
369 The capacity-aware scheduling (CAS) support in the CPU scheduler is enabled by
370 ``intel_pstate`` by default on hybrid processors without SMT. CAS generally
371 causes the scheduler to put tasks on a CPU so long as there is a sufficient
372 amount of spare capacity on it, and if the utilization of a given task is too
373 high for it, the task will need to go somewhere else.
375 Since CAS takes CPU capacities into account, it does not require CPU
376 prioritization and it allows tasks to be distributed more symmetrically among
377 the more performant and less performant CPUs. Once placed on a CPU with enough
378 capacity to accommodate it, a task may just continue to run there regardless of
379 whether or not the other CPUs are fully loaded, so on average CAS reduces the
380 utilization of the more performant CPUs which causes the energy usage to be more
381 balanced because the more performant CPUs are generally less energy-efficient
382 than the less performant ones.
384 In order to use CAS, the scheduler needs to know the capacity of each CPU in
385 the system and it needs to be able to compute scale-invariant utilization of
386 CPUs, so ``intel_pstate`` provides it with the requisite information.
388 First of all, the capacity of each CPU is represented by the ratio of its highest
389 HWP performance level, multiplied by 1024, to the highest HWP performance level
390 of the most performant CPU in the system, which works because the HWP performance
391 units are the same for all CPUs. Second, the frequency-invariance computations,
392 carried out by the scheduler to always express CPU utilization in the same units
393 regardless of the frequency it is currently running at, are adjusted to take the
394 CPU capacity into account. All of this happens when ``intel_pstate`` has
395 registered itself with the ``CPUFreq`` core and it has figured out that it is
396 running on a hybrid processor without SMT.
398 Energy-Aware Scheduling Support
399 -------------------------------
401 If ``CONFIG_ENERGY_MODEL`` has been set during kernel configuration and
402 ``intel_pstate`` runs on a hybrid processor without SMT, in addition to enabling
403 `CAS <CAS_>`_ it registers an Energy Model for the processor. This allows the
404 Energy-Aware Scheduling (EAS) support to be enabled in the CPU scheduler if
405 ``schedutil`` is used as the ``CPUFreq`` governor which requires ``intel_pstate``
406 to operate in the `passive mode <Passive Mode_>`_.
408 The Energy Model registered by ``intel_pstate`` is artificial (that is, it is
409 based on abstract cost values and it does not include any real power numbers)
410 and it is relatively simple to avoid unnecessary computations in the scheduler.
411 There is a performance domain in it for every CPU in the system and the cost
412 values for these performance domains have been chosen so that running a task on
413 a less performant (small) CPU appears to be always cheaper than running that
414 task on a more performant (big) CPU. However, for two CPUs of the same type,
415 the cost difference depends on their current utilization, and the CPU whose
416 current utilization is higher generally appears to be a more expensive
417 destination for a given task. This helps to balance the load among CPUs of the
420 Since EAS works on top of CAS, high-utilization tasks are always migrated to
421 CPUs with enough capacity to accommodate them, but thanks to EAS, low-utilization
422 tasks tend to be placed on the CPUs that look less expensive to the scheduler.
423 Effectively, this causes the less performant and less loaded CPUs to be
424 preferred as long as they have enough spare capacity to run the given task
425 which generally leads to reduced energy usage.
427 The Energy Model created by ``intel_pstate`` can be inspected by looking at
428 the ``energy_model`` directory in ``debugfs`` (typlically mounted on
429 ``/sys/kernel/debug/``).
432 User Space Interface in ``sysfs``
433 =================================
438 ``intel_pstate`` exposes several global attributes (files) in ``sysfs`` to
439 control its functionality at the system level. They are located in the
440 ``/sys/devices/system/cpu/intel_pstate/`` directory and affect all CPUs.
442 Some of them are not present if the ``intel_pstate=per_cpu_perf_limits``
443 argument is passed to the kernel in the command line.
446 Maximum P-state the driver is allowed to set in percent of the
447 maximum supported performance level (the highest supported `turbo
450 This attribute will not be exposed if the
451 ``intel_pstate=per_cpu_perf_limits`` argument is present in the kernel
455 Minimum P-state the driver is allowed to set in percent of the
456 maximum supported performance level (the highest supported `turbo
459 This attribute will not be exposed if the
460 ``intel_pstate=per_cpu_perf_limits`` argument is present in the kernel
464 Number of P-states supported by the processor (between 0 and 255
465 inclusive) including both turbo and non-turbo P-states (see
466 `Turbo P-states Support`_).
468 This attribute is present only if the value exposed by it is the same
469 for all of the CPUs in the system.
471 The value of this attribute is not affected by the ``no_turbo``
472 setting described `below <no_turbo_attr_>`_.
474 This attribute is read-only.
477 Ratio of the `turbo range <turbo_>`_ size to the size of the entire
478 range of supported P-states, in percent.
480 This attribute is present only if the value exposed by it is the same
481 for all of the CPUs in the system.
483 This attribute is read-only.
488 If set (equal to 1), the driver is not allowed to set any turbo P-states
489 (see `Turbo P-states Support`_). If unset (equal to 0, which is the
490 default), turbo P-states can be set by the driver.
491 [Note that ``intel_pstate`` does not support the general ``boost``
492 attribute (supported by some other scaling drivers) which is replaced
495 This attribute does not affect the maximum supported frequency value
496 supplied to the ``CPUFreq`` core and exposed via the policy interface,
497 but it affects the maximum possible value of per-policy P-state limits
498 (see `Interpretation of Policy Attributes`_ below for details).
500 ``hwp_dynamic_boost``
501 This attribute is only present if ``intel_pstate`` works in the
502 `active mode with the HWP feature enabled <Active Mode With HWP_>`_ in
503 the processor. If set (equal to 1), it causes the minimum P-state limit
504 to be increased dynamically for a short time whenever a task previously
505 waiting on I/O is selected to run on a given logical CPU (the purpose
506 of this mechanism is to improve performance).
508 This setting has no effect on logical CPUs whose minimum P-state limit
509 is directly set to the highest non-turbo P-state or above it.
514 Operation mode of the driver: "active", "passive" or "off".
517 The driver is functional and in the `active mode
521 The driver is functional and in the `passive mode
525 The driver is not functional (it is not registered as a scaling
526 driver with the ``CPUFreq`` core).
528 This attribute can be written to in order to change the driver's
529 operation mode or to unregister it. The string written to it must be
530 one of the possible values of it and, if successful, the write will
531 cause the driver to switch over to the operation mode represented by
532 that string - or to be unregistered in the "off" case. [Actually,
533 switching over from the active mode to the passive mode or the other
534 way around causes the driver to be unregistered and registered again
535 with a different set of callbacks, so all of its settings (the global
536 as well as the per-policy ones) are then reset to their default
537 values, possibly depending on the target operation mode.]
539 ``energy_efficiency``
540 This attribute is only present on platforms with CPUs matching the Kaby
541 Lake or Coffee Lake desktop CPU model. By default, energy-efficiency
542 optimizations are disabled on these CPU models if HWP is enabled.
543 Enabling energy-efficiency optimizations may limit maximum operating
544 frequency with or without the HWP feature. With HWP enabled, the
545 optimizations are done only in the turbo frequency range. Without it,
546 they are done in the entire available frequency range. Setting this
547 attribute to "1" enables the energy-efficiency optimizations and setting
548 to "0" disables them.
550 Interpretation of Policy Attributes
551 -----------------------------------
553 The interpretation of some ``CPUFreq`` policy attributes described in
554 Documentation/admin-guide/pm/cpufreq.rst is special with ``intel_pstate``
555 as the current scaling driver and it generally depends on the driver's
556 `operation mode <Operation Modes_>`_.
558 First of all, the values of the ``cpuinfo_max_freq``, ``cpuinfo_min_freq`` and
559 ``scaling_cur_freq`` attributes are produced by applying a processor-specific
560 multiplier to the internal P-state representation used by ``intel_pstate``.
561 Also, the values of the ``scaling_max_freq`` and ``scaling_min_freq``
562 attributes are capped by the frequency corresponding to the maximum P-state that
563 the driver is allowed to set.
565 If the ``no_turbo`` `global attribute <no_turbo_attr_>`_ is set, the driver is
566 not allowed to use turbo P-states, so the maximum value of ``scaling_max_freq``
567 and ``scaling_min_freq`` is limited to the maximum non-turbo P-state frequency.
568 Accordingly, setting ``no_turbo`` causes ``scaling_max_freq`` and
569 ``scaling_min_freq`` to go down to that value if they were above it before.
570 However, the old values of ``scaling_max_freq`` and ``scaling_min_freq`` will be
571 restored after unsetting ``no_turbo``, unless these attributes have been written
572 to after ``no_turbo`` was set.
574 If ``no_turbo`` is not set, the maximum possible value of ``scaling_max_freq``
575 and ``scaling_min_freq`` corresponds to the maximum supported turbo P-state,
576 which also is the value of ``cpuinfo_max_freq`` in either case.
578 Next, the following policy attributes have special meaning if
579 ``intel_pstate`` works in the `active mode <Active Mode_>`_:
581 ``scaling_available_governors``
582 List of P-state selection algorithms provided by ``intel_pstate``.
585 P-state selection algorithm provided by ``intel_pstate`` currently in
586 use with the given policy.
589 Frequency of the average P-state of the CPU represented by the given
590 policy for the time interval between the last two invocations of the
591 driver's utilization update callback by the CPU scheduler for that CPU.
593 One more policy attribute is present if the HWP feature is enabled in the
597 Shows the base frequency of the CPU. Any frequency above this will be
598 in the turbo frequency range.
600 The meaning of these attributes in the `passive mode <Passive Mode_>`_ is the
601 same as for other scaling drivers.
603 Additionally, the value of the ``scaling_driver`` attribute for ``intel_pstate``
604 depends on the operation mode of the driver. Namely, it is either
605 "intel_pstate" (in the `active mode <Active Mode_>`_) or "intel_cpufreq" (in the
606 `passive mode <Passive Mode_>`_).
608 Coordination of P-State Limits
609 ------------------------------
611 ``intel_pstate`` allows P-state limits to be set in two ways: with the help of
612 the ``max_perf_pct`` and ``min_perf_pct`` `global attributes
613 <Global Attributes_>`_ or via the ``scaling_max_freq`` and ``scaling_min_freq``
614 ``CPUFreq`` policy attributes. The coordination between those limits is based
615 on the following rules, regardless of the current operation mode of the driver:
617 1. All CPUs are affected by the global limits (that is, none of them can be
618 requested to run faster than the global maximum and none of them can be
619 requested to run slower than the global minimum).
621 2. Each individual CPU is affected by its own per-policy limits (that is, it
622 cannot be requested to run faster than its own per-policy maximum and it
623 cannot be requested to run slower than its own per-policy minimum). The
624 effective performance depends on whether the platform supports per core
625 P-states, hyper-threading is enabled and on current performance requests
626 from other CPUs. When platform doesn't support per core P-states, the
627 effective performance can be more than the policy limits set on a CPU, if
628 other CPUs are requesting higher performance at that moment. Even with per
629 core P-states support, when hyper-threading is enabled, if the sibling CPU
630 is requesting higher performance, the other siblings will get higher
631 performance than their policy limits.
633 3. The global and per-policy limits can be set independently.
635 In the `active mode with the HWP feature enabled <Active Mode With HWP_>`_, the
636 resulting effective values are written into hardware registers whenever the
637 limits change in order to request its internal P-state selection logic to always
638 set P-states within these limits. Otherwise, the limits are taken into account
639 by scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver
640 every time before setting a new P-state for a CPU.
642 Additionally, if the ``intel_pstate=per_cpu_perf_limits`` command line argument
643 is passed to the kernel, ``max_perf_pct`` and ``min_perf_pct`` are not exposed
644 at all and the only way to set the limits is by using the policy attributes.
647 Energy vs Performance Hints
648 ---------------------------
650 If the hardware-managed P-states (HWP) is enabled in the processor, additional
651 attributes, intended to allow user space to help ``intel_pstate`` to adjust the
652 processor's internal P-state selection logic by focusing it on performance or on
653 energy-efficiency, or somewhere between the two extremes, are present in every
654 ``CPUFreq`` policy directory in ``sysfs``. They are :
656 ``energy_performance_preference``
657 Current value of the energy vs performance hint for the given policy
658 (or the CPU represented by it).
660 The hint can be changed by writing to this attribute.
662 ``energy_performance_available_preferences``
663 List of strings that can be written to the
664 ``energy_performance_preference`` attribute.
666 They represent different energy vs performance hints and should be
667 self-explanatory, except that ``default`` represents whatever hint
668 value was set by the platform firmware.
670 Strings written to the ``energy_performance_preference`` attribute are
671 internally translated to integer values written to the processor's
672 Energy-Performance Preference (EPP) knob (if supported) or its
673 Energy-Performance Bias (EPB) knob. It is also possible to write a positive
674 integer value between 0 to 255, if the EPP feature is present. If the EPP
675 feature is not present, writing integer value to this attribute is not
676 supported. In this case, user can use the
677 "/sys/devices/system/cpu/cpu*/power/energy_perf_bias" interface.
679 [Note that tasks may by migrated from one CPU to another by the scheduler's
680 load-balancing algorithm and if different energy vs performance hints are
681 set for those CPUs, that may lead to undesirable outcomes. To avoid such
682 issues it is better to set the same energy vs performance hint for all CPUs
683 or to pin every task potentially sensitive to them to a specific CPU.]
687 ``intel_pstate`` vs ``acpi-cpufreq``
688 ====================================
690 On the majority of systems supported by ``intel_pstate``, the ACPI tables
691 provided by the platform firmware contain ``_PSS`` objects returning information
692 that can be used for CPU performance scaling (refer to the ACPI specification
693 [3]_ for details on the ``_PSS`` objects and the format of the information
696 The information returned by the ACPI ``_PSS`` objects is used by the
697 ``acpi-cpufreq`` scaling driver. On systems supported by ``intel_pstate``
698 the ``acpi-cpufreq`` driver uses the same hardware CPU performance scaling
699 interface, but the set of P-states it can use is limited by the ``_PSS``
702 On those systems each ``_PSS`` object returns a list of P-states supported by
703 the corresponding CPU which basically is a subset of the P-states range that can
704 be used by ``intel_pstate`` on the same system, with one exception: the whole
705 `turbo range <turbo_>`_ is represented by one item in it (the topmost one). By
706 convention, the frequency returned by ``_PSS`` for that item is greater by 1 MHz
707 than the frequency of the highest non-turbo P-state listed by it, but the
708 corresponding P-state representation (following the hardware specification)
709 returned for it matches the maximum supported turbo P-state (or is the
710 special value 255 meaning essentially "go as high as you can get").
712 The list of P-states returned by ``_PSS`` is reflected by the table of
713 available frequencies supplied by ``acpi-cpufreq`` to the ``CPUFreq`` core and
714 scaling governors and the minimum and maximum supported frequencies reported by
715 it come from that list as well. In particular, given the special representation
716 of the turbo range described above, this means that the maximum supported
717 frequency reported by ``acpi-cpufreq`` is higher by 1 MHz than the frequency
718 of the highest supported non-turbo P-state listed by ``_PSS`` which, of course,
719 affects decisions made by the scaling governors, except for ``powersave`` and
722 For example, if a given governor attempts to select a frequency proportional to
723 estimated CPU load and maps the load of 100% to the maximum supported frequency
724 (possibly multiplied by a constant), then it will tend to choose P-states below
725 the turbo threshold if ``acpi-cpufreq`` is used as the scaling driver, because
726 in that case the turbo range corresponds to a small fraction of the frequency
727 band it can use (1 MHz vs 1 GHz or more). In consequence, it will only go to
728 the turbo range for the highest loads and the other loads above 50% that might
729 benefit from running at turbo frequencies will be given non-turbo P-states
732 One more issue related to that may appear on systems supporting the
733 `Configurable TDP feature <turbo_>`_ allowing the platform firmware to set the
734 turbo threshold. Namely, if that is not coordinated with the lists of P-states
735 returned by ``_PSS`` properly, there may be more than one item corresponding to
736 a turbo P-state in those lists and there may be a problem with avoiding the
737 turbo range (if desirable or necessary). Usually, to avoid using turbo
738 P-states overall, ``acpi-cpufreq`` simply avoids using the topmost state listed
739 by ``_PSS``, but that is not sufficient when there are other turbo P-states in
740 the list returned by it.
742 Apart from the above, ``acpi-cpufreq`` works like ``intel_pstate`` in the
743 `passive mode <Passive Mode_>`_, except that the number of P-states it can set
744 is limited to the ones listed by the ACPI ``_PSS`` objects.
747 Kernel Command Line Options for ``intel_pstate``
748 ================================================
750 Several kernel command line options can be used to pass early-configuration-time
751 parameters to ``intel_pstate`` in order to enforce specific behavior of it. All
752 of them have to be prepended with the ``intel_pstate=`` prefix.
755 Do not register ``intel_pstate`` as the scaling driver even if the
756 processor is supported by it.
759 Register ``intel_pstate`` in the `active mode <Active Mode_>`_ to start
763 Register ``intel_pstate`` in the `passive mode <Passive Mode_>`_ to
767 Register ``intel_pstate`` as the scaling driver instead of
768 ``acpi-cpufreq`` even if the latter is preferred on the given system.
770 This may prevent some platform features (such as thermal controls and
771 power capping) that rely on the availability of ACPI P-states
772 information from functioning as expected, so it should be used with
775 This option does not work with processors that are not supported by
776 ``intel_pstate`` and on platforms where the ``pcc-cpufreq`` scaling
777 driver is used instead of ``acpi-cpufreq``.
780 Do not enable the hardware-managed P-states (HWP) feature even if it is
781 supported by the processor.
784 Register ``intel_pstate`` as the scaling driver only if the
785 hardware-managed P-states (HWP) feature is supported by the processor.
788 Take ACPI ``_PPC`` performance limits into account.
790 If the preferred power management profile in the FADT (Fixed ACPI
791 Description Table) is set to "Enterprise Server" or "Performance
792 Server", the ACPI ``_PPC`` limits are taken into account by default
793 and this option has no effect.
795 ``per_cpu_perf_limits``
796 Use per-logical-CPU P-State limits (see `Coordination of P-state
797 Limits`_ for details).
800 Do not enable `capacity-aware scheduling <CAS_>`_ which is enabled by
801 default on hybrid systems without SMT.
803 Diagnostics and Tuning
804 ======================
809 There are two static trace events that can be used for ``intel_pstate``
810 diagnostics. One of them is the ``cpu_frequency`` trace event generally used
811 by ``CPUFreq``, and the other one is the ``pstate_sample`` trace event specific
812 to ``intel_pstate``. Both of them are triggered by ``intel_pstate`` only if
813 it works in the `active mode <Active Mode_>`_.
815 The following sequence of shell commands can be used to enable them and see
816 their output (if the kernel is generally configured to support event tracing)::
818 # cd /sys/kernel/tracing/
819 # echo 1 > events/power/pstate_sample/enable
820 # echo 1 > events/power/cpu_frequency/enable
822 gnome-terminal--4510 [001] ..s. 1177.680733: pstate_sample: core_busy=107 scaled=94 from=26 to=26 mperf=1143818 aperf=1230607 tsc=29838618 freq=2474476
823 cat-5235 [002] ..s. 1177.681723: cpu_frequency: state=2900000 cpu_id=2
825 If ``intel_pstate`` works in the `passive mode <Passive Mode_>`_, the
826 ``cpu_frequency`` trace event will be triggered either by the ``schedutil``
827 scaling governor (for the policies it is attached to), or by the ``CPUFreq``
828 core (for the policies with other scaling governors).
833 The ``ftrace`` interface can be used for low-level diagnostics of
834 ``intel_pstate``. For example, to check how often the function to set a
835 P-state is called, the ``ftrace`` filter can be set to
836 :c:func:`intel_pstate_set_pstate`::
838 # cd /sys/kernel/tracing/
839 # cat available_filter_functions | grep -i pstate
840 intel_pstate_set_pstate
841 intel_pstate_cpu_init
843 # echo intel_pstate_set_pstate > set_ftrace_filter
844 # echo function > current_tracer
845 # cat trace | head -15
848 # entries-in-buffer/entries-written: 80/80 #P:4
851 # / _----=> need-resched
852 # | / _---=> hardirq/softirq
853 # || / _--=> preempt-depth
855 # TASK-PID CPU# |||| TIMESTAMP FUNCTION
857 Xorg-3129 [000] ..s. 2537.644844: intel_pstate_set_pstate <-intel_pstate_timer_func
858 gnome-terminal--4510 [002] ..s. 2537.649844: intel_pstate_set_pstate <-intel_pstate_timer_func
859 gnome-shell-3409 [001] ..s. 2537.650850: intel_pstate_set_pstate <-intel_pstate_timer_func
860 <idle>-0 [000] ..s. 2537.654843: intel_pstate_set_pstate <-intel_pstate_timer_func
866 .. [1] Kristen Accardi, *Balancing Power and Performance in the Linux Kernel*,
867 https://events.static.linuxfound.org/sites/events/files/slides/LinuxConEurope_2015.pdf
869 .. [2] *Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3: System Programming Guide*,
870 https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-system-programming-manual-325384.html
872 .. [3] *Advanced Configuration and Power Interface Specification*,
873 https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
projects / linux-2.6-block.git / blob