771 lines · plain
1.. SPDX-License-Identifier: GPL-2.02.. include:: <isonum.txt>3 4===============================================5``intel_pstate`` CPU Performance Scaling Driver6===============================================7 8:Copyright: |copy| 2017 Intel Corporation9 10:Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>11 12 13General Information14===================15 16``intel_pstate`` is a part of the17:doc:`CPU performance scaling subsystem <cpufreq>` in the Linux kernel18(``CPUFreq``). It is a scaling driver for the Sandy Bridge and later19generations of Intel processors. Note, however, that some of those processors20may not be supported. [To understand ``intel_pstate`` it is necessary to know21how ``CPUFreq`` works in general, so this is the time to read22Documentation/admin-guide/pm/cpufreq.rst if you have not done that yet.]23 24For the processors supported by ``intel_pstate``, the P-state concept is broader25than just an operating frequency or an operating performance point (see the26LinuxCon Europe 2015 presentation by Kristen Accardi [1]_ for more27information about that). For this reason, the representation of P-states used28by ``intel_pstate`` internally follows the hardware specification (for details29refer to Intel Software Developer’s Manual [2]_). However, the ``CPUFreq`` core30uses frequencies for identifying operating performance points of CPUs and31frequencies are involved in the user space interface exposed by it, so32``intel_pstate`` maps its internal representation of P-states to frequencies too33(fortunately, that mapping is unambiguous). At the same time, it would not be34practical for ``intel_pstate`` to supply the ``CPUFreq`` core with a table of35available frequencies due to the possible size of it, so the driver does not do36that. Some functionality of the core is limited by that.37 38Since the hardware P-state selection interface used by ``intel_pstate`` is39available at the logical CPU level, the driver always works with individual40CPUs. Consequently, if ``intel_pstate`` is in use, every ``CPUFreq`` policy41object corresponds to one logical CPU and ``CPUFreq`` policies are effectively42equivalent to CPUs. In particular, this means that they become "inactive" every43time the corresponding CPU is taken offline and need to be re-initialized when44it goes back online.45 46``intel_pstate`` is not modular, so it cannot be unloaded, which means that the47only way to pass early-configuration-time parameters to it is via the kernel48command line. However, its configuration can be adjusted via ``sysfs`` to a49great extent. In some configurations it even is possible to unregister it via50``sysfs`` which allows another ``CPUFreq`` scaling driver to be loaded and51registered (see `below <status_attr_>`_).52 53 54Operation Modes55===============56 57``intel_pstate`` can operate in two different modes, active or passive. In the58active mode, it uses its own internal performance scaling governor algorithm or59allows the hardware to do performance scaling by itself, while in the passive60mode it responds to requests made by a generic ``CPUFreq`` governor implementing61a certain performance scaling algorithm. Which of them will be in effect62depends on what kernel command line options are used and on the capabilities of63the processor.64 65Active Mode66-----------67 68This is the default operation mode of ``intel_pstate`` for processors with69hardware-managed P-states (HWP) support. If it works in this mode, the70``scaling_driver`` policy attribute in ``sysfs`` for all ``CPUFreq`` policies71contains the string "intel_pstate".72 73In this mode the driver bypasses the scaling governors layer of ``CPUFreq`` and74provides its own scaling algorithms for P-state selection. Those algorithms75can be applied to ``CPUFreq`` policies in the same way as generic scaling76governors (that is, through the ``scaling_governor`` policy attribute in77``sysfs``). [Note that different P-state selection algorithms may be chosen for78different policies, but that is not recommended.]79 80They are not generic scaling governors, but their names are the same as the81names of some of those governors. Moreover, confusingly enough, they generally82do not work in the same way as the generic governors they share the names with.83For example, the ``powersave`` P-state selection algorithm provided by84``intel_pstate`` is not a counterpart of the generic ``powersave`` governor85(roughly, it corresponds to the ``schedutil`` and ``ondemand`` governors).86 87There are two P-state selection algorithms provided by ``intel_pstate`` in the88active mode: ``powersave`` and ``performance``. The way they both operate89depends on whether or not the hardware-managed P-states (HWP) feature has been90enabled in the processor and possibly on the processor model.91 92Which of the P-state selection algorithms is used by default depends on the93:c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option.94Namely, if that option is set, the ``performance`` algorithm will be used by95default, and the other one will be used by default if it is not set.96 97Active Mode With HWP98~~~~~~~~~~~~~~~~~~~~99 100If the processor supports the HWP feature, it will be enabled during the101processor initialization and cannot be disabled after that. It is possible102to avoid enabling it by passing the ``intel_pstate=no_hwp`` argument to the103kernel in the command line.104 105If the HWP feature has been enabled, ``intel_pstate`` relies on the processor to106select P-states by itself, but still it can give hints to the processor's107internal P-state selection logic. What those hints are depends on which P-state108selection algorithm has been applied to the given policy (or to the CPU it109corresponds to).110 111Even though the P-state selection is carried out by the processor automatically,112``intel_pstate`` registers utilization update callbacks with the CPU scheduler113in this mode. However, they are not used for running a P-state selection114algorithm, but for periodic updates of the current CPU frequency information to115be made available from the ``scaling_cur_freq`` policy attribute in ``sysfs``.116 117HWP + ``performance``118.....................119 120In this configuration ``intel_pstate`` will write 0 to the processor's121Energy-Performance Preference (EPP) knob (if supported) or its122Energy-Performance Bias (EPB) knob (otherwise), which means that the processor's123internal P-state selection logic is expected to focus entirely on performance.124 125This will override the EPP/EPB setting coming from the ``sysfs`` interface126(see `Energy vs Performance Hints`_ below). Moreover, any attempts to change127the EPP/EPB to a value different from 0 ("performance") via ``sysfs`` in this128configuration will be rejected.129 130Also, in this configuration the range of P-states available to the processor's131internal P-state selection logic is always restricted to the upper boundary132(that is, the maximum P-state that the driver is allowed to use).133 134HWP + ``powersave``135...................136 137In this configuration ``intel_pstate`` will set the processor's138Energy-Performance Preference (EPP) knob (if supported) or its139Energy-Performance Bias (EPB) knob (otherwise) to whatever value it was140previously set to via ``sysfs`` (or whatever default value it was141set to by the platform firmware). This usually causes the processor's142internal P-state selection logic to be less performance-focused.143 144Active Mode Without HWP145~~~~~~~~~~~~~~~~~~~~~~~146 147This operation mode is optional for processors that do not support the HWP148feature or when the ``intel_pstate=no_hwp`` argument is passed to the kernel in149the command line. The active mode is used in those cases if the150``intel_pstate=active`` argument is passed to the kernel in the command line.151In this mode ``intel_pstate`` may refuse to work with processors that are not152recognized by it. [Note that ``intel_pstate`` will never refuse to work with153any processor with the HWP feature enabled.]154 155In this mode ``intel_pstate`` registers utilization update callbacks with the156CPU scheduler in order to run a P-state selection algorithm, either157``powersave`` or ``performance``, depending on the ``scaling_governor`` policy158setting in ``sysfs``. The current CPU frequency information to be made159available from the ``scaling_cur_freq`` policy attribute in ``sysfs`` is160periodically updated by those utilization update callbacks too.161 162``performance``163...............164 165Without HWP, this P-state selection algorithm is always the same regardless of166the processor model and platform configuration.167 168It selects the maximum P-state it is allowed to use, subject to limits set via169``sysfs``, every time the driver configuration for the given CPU is updated170(e.g. via ``sysfs``).171 172This is the default P-state selection algorithm if the173:c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option174is set.175 176``powersave``177.............178 179Without HWP, this P-state selection algorithm is similar to the algorithm180implemented by the generic ``schedutil`` scaling governor except that the181utilization metric used by it is based on numbers coming from feedback182registers of the CPU. It generally selects P-states proportional to the183current CPU utilization.184 185This algorithm is run by the driver's utilization update callback for the186given CPU when it is invoked by the CPU scheduler, but not more often than187every 10 ms. Like in the ``performance`` case, the hardware configuration188is not touched if the new P-state turns out to be the same as the current189one.190 191This is the default P-state selection algorithm if the192:c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option193is not set.194 195Passive Mode196------------197 198This is the default operation mode of ``intel_pstate`` for processors without199hardware-managed P-states (HWP) support. It is always used if the200``intel_pstate=passive`` argument is passed to the kernel in the command line201regardless of whether or not the given processor supports HWP. [Note that the202``intel_pstate=no_hwp`` setting causes the driver to start in the passive mode203if it is not combined with ``intel_pstate=active``.] Like in the active mode204without HWP support, in this mode ``intel_pstate`` may refuse to work with205processors that are not recognized by it if HWP is prevented from being enabled206through the kernel command line.207 208If the driver works in this mode, the ``scaling_driver`` policy attribute in209``sysfs`` for all ``CPUFreq`` policies contains the string "intel_cpufreq".210Then, the driver behaves like a regular ``CPUFreq`` scaling driver. That is,211it is invoked by generic scaling governors when necessary to talk to the212hardware in order to change the P-state of a CPU (in particular, the213``schedutil`` governor can invoke it directly from scheduler context).214 215While in this mode, ``intel_pstate`` can be used with all of the (generic)216scaling governors listed by the ``scaling_available_governors`` policy attribute217in ``sysfs`` (and the P-state selection algorithms described above are not218used). Then, it is responsible for the configuration of policy objects219corresponding to CPUs and provides the ``CPUFreq`` core (and the scaling220governors attached to the policy objects) with accurate information on the221maximum and minimum operating frequencies supported by the hardware (including222the so-called "turbo" frequency ranges). In other words, in the passive mode223the entire range of available P-states is exposed by ``intel_pstate`` to the224``CPUFreq`` core. However, in this mode the driver does not register225utilization update callbacks with the CPU scheduler and the ``scaling_cur_freq``226information comes from the ``CPUFreq`` core (and is the last frequency selected227by the current scaling governor for the given policy).228 229 230.. _turbo:231 232Turbo P-states Support233======================234 235In the majority of cases, the entire range of P-states available to236``intel_pstate`` can be divided into two sub-ranges that correspond to237different types of processor behavior, above and below a boundary that238will be referred to as the "turbo threshold" in what follows.239 240The P-states above the turbo threshold are referred to as "turbo P-states" and241the whole sub-range of P-states they belong to is referred to as the "turbo242range". These names are related to the Turbo Boost technology allowing a243multicore processor to opportunistically increase the P-state of one or more244cores if there is enough power to do that and if that is not going to cause the245thermal envelope of the processor package to be exceeded.246 247Specifically, if software sets the P-state of a CPU core within the turbo range248(that is, above the turbo threshold), the processor is permitted to take over249performance scaling control for that core and put it into turbo P-states of its250choice going forward. However, that permission is interpreted differently by251different processor generations. Namely, the Sandy Bridge generation of252processors will never use any P-states above the last one set by software for253the given core, even if it is within the turbo range, whereas all of the later254processor generations will take it as a license to use any P-states from the255turbo range, even above the one set by software. In other words, on those256processors setting any P-state from the turbo range will enable the processor257to put the given core into all turbo P-states up to and including the maximum258supported one as it sees fit.259 260One important property of turbo P-states is that they are not sustainable. More261precisely, there is no guarantee that any CPUs will be able to stay in any of262those states indefinitely, because the power distribution within the processor263package may change over time or the thermal envelope it was designed for might264be exceeded if a turbo P-state was used for too long.265 266In turn, the P-states below the turbo threshold generally are sustainable. In267fact, if one of them is set by software, the processor is not expected to change268it to a lower one unless in a thermal stress or a power limit violation269situation (a higher P-state may still be used if it is set for another CPU in270the same package at the same time, for example).271 272Some processors allow multiple cores to be in turbo P-states at the same time,273but the maximum P-state that can be set for them generally depends on the number274of cores running concurrently. The maximum turbo P-state that can be set for 3275cores at the same time usually is lower than the analogous maximum P-state for2762 cores, which in turn usually is lower than the maximum turbo P-state that can277be set for 1 core. The one-core maximum turbo P-state is thus the maximum278supported one overall.279 280The maximum supported turbo P-state, the turbo threshold (the maximum supported281non-turbo P-state) and the minimum supported P-state are specific to the282processor model and can be determined by reading the processor's model-specific283registers (MSRs). Moreover, some processors support the Configurable TDP284(Thermal Design Power) feature and, when that feature is enabled, the turbo285threshold effectively becomes a configurable value that can be set by the286platform firmware.287 288Unlike ``_PSS`` objects in the ACPI tables, ``intel_pstate`` always exposes289the entire range of available P-states, including the whole turbo range, to the290``CPUFreq`` core and (in the passive mode) to generic scaling governors. This291generally causes turbo P-states to be set more often when ``intel_pstate`` is292used relative to ACPI-based CPU performance scaling (see `below <acpi-cpufreq_>`_293for more information).294 295Moreover, since ``intel_pstate`` always knows what the real turbo threshold is296(even if the Configurable TDP feature is enabled in the processor), its297``no_turbo`` attribute in ``sysfs`` (described `below <no_turbo_attr_>`_) should298work as expected in all cases (that is, if set to disable turbo P-states, it299always should prevent ``intel_pstate`` from using them).300 301 302Processor Support303=================304 305To handle a given processor ``intel_pstate`` requires a number of different306pieces of information on it to be known, including:307 308 * The minimum supported P-state.309 310 * The maximum supported `non-turbo P-state <turbo_>`_.311 312 * Whether or not turbo P-states are supported at all.313 314 * The maximum supported `one-core turbo P-state <turbo_>`_ (if turbo P-states315 are supported).316 317 * The scaling formula to translate the driver's internal representation318 of P-states into frequencies and the other way around.319 320Generally, ways to obtain that information are specific to the processor model321or family. Although it often is possible to obtain all of it from the processor322itself (using model-specific registers), there are cases in which hardware323manuals need to be consulted to get to it too.324 325For this reason, there is a list of supported processors in ``intel_pstate`` and326the driver initialization will fail if the detected processor is not in that327list, unless it supports the HWP feature. [The interface to obtain all of the328information listed above is the same for all of the processors supporting the329HWP feature, which is why ``intel_pstate`` works with all of them.]330 331 332User Space Interface in ``sysfs``333=================================334 335Global Attributes336-----------------337 338``intel_pstate`` exposes several global attributes (files) in ``sysfs`` to339control its functionality at the system level. They are located in the340``/sys/devices/system/cpu/intel_pstate/`` directory and affect all CPUs.341 342Some of them are not present if the ``intel_pstate=per_cpu_perf_limits``343argument is passed to the kernel in the command line.344 345``max_perf_pct``346 Maximum P-state the driver is allowed to set in percent of the347 maximum supported performance level (the highest supported `turbo348 P-state <turbo_>`_).349 350 This attribute will not be exposed if the351 ``intel_pstate=per_cpu_perf_limits`` argument is present in the kernel352 command line.353 354``min_perf_pct``355 Minimum P-state the driver is allowed to set in percent of the356 maximum supported performance level (the highest supported `turbo357 P-state <turbo_>`_).358 359 This attribute will not be exposed if the360 ``intel_pstate=per_cpu_perf_limits`` argument is present in the kernel361 command line.362 363``num_pstates``364 Number of P-states supported by the processor (between 0 and 255365 inclusive) including both turbo and non-turbo P-states (see366 `Turbo P-states Support`_).367 368 This attribute is present only if the value exposed by it is the same369 for all of the CPUs in the system.370 371 The value of this attribute is not affected by the ``no_turbo``372 setting described `below <no_turbo_attr_>`_.373 374 This attribute is read-only.375 376``turbo_pct``377 Ratio of the `turbo range <turbo_>`_ size to the size of the entire378 range of supported P-states, in percent.379 380 This attribute is present only if the value exposed by it is the same381 for all of the CPUs in the system.382 383 This attribute is read-only.384 385.. _no_turbo_attr:386 387``no_turbo``388 If set (equal to 1), the driver is not allowed to set any turbo P-states389 (see `Turbo P-states Support`_). If unset (equal to 0, which is the390 default), turbo P-states can be set by the driver.391 [Note that ``intel_pstate`` does not support the general ``boost``392 attribute (supported by some other scaling drivers) which is replaced393 by this one.]394 395 This attribute does not affect the maximum supported frequency value396 supplied to the ``CPUFreq`` core and exposed via the policy interface,397 but it affects the maximum possible value of per-policy P-state limits398 (see `Interpretation of Policy Attributes`_ below for details).399 400``hwp_dynamic_boost``401 This attribute is only present if ``intel_pstate`` works in the402 `active mode with the HWP feature enabled <Active Mode With HWP_>`_ in403 the processor. If set (equal to 1), it causes the minimum P-state limit404 to be increased dynamically for a short time whenever a task previously405 waiting on I/O is selected to run on a given logical CPU (the purpose406 of this mechanism is to improve performance).407 408 This setting has no effect on logical CPUs whose minimum P-state limit409 is directly set to the highest non-turbo P-state or above it.410 411.. _status_attr:412 413``status``414 Operation mode of the driver: "active", "passive" or "off".415 416 "active"417 The driver is functional and in the `active mode418 <Active Mode_>`_.419 420 "passive"421 The driver is functional and in the `passive mode422 <Passive Mode_>`_.423 424 "off"425 The driver is not functional (it is not registered as a scaling426 driver with the ``CPUFreq`` core).427 428 This attribute can be written to in order to change the driver's429 operation mode or to unregister it. The string written to it must be430 one of the possible values of it and, if successful, the write will431 cause the driver to switch over to the operation mode represented by432 that string - or to be unregistered in the "off" case. [Actually,433 switching over from the active mode to the passive mode or the other434 way around causes the driver to be unregistered and registered again435 with a different set of callbacks, so all of its settings (the global436 as well as the per-policy ones) are then reset to their default437 values, possibly depending on the target operation mode.]438 439``energy_efficiency``440 This attribute is only present on platforms with CPUs matching the Kaby441 Lake or Coffee Lake desktop CPU model. By default, energy-efficiency442 optimizations are disabled on these CPU models if HWP is enabled.443 Enabling energy-efficiency optimizations may limit maximum operating444 frequency with or without the HWP feature. With HWP enabled, the445 optimizations are done only in the turbo frequency range. Without it,446 they are done in the entire available frequency range. Setting this447 attribute to "1" enables the energy-efficiency optimizations and setting448 to "0" disables them.449 450Interpretation of Policy Attributes451-----------------------------------452 453The interpretation of some ``CPUFreq`` policy attributes described in454Documentation/admin-guide/pm/cpufreq.rst is special with ``intel_pstate``455as the current scaling driver and it generally depends on the driver's456`operation mode <Operation Modes_>`_.457 458First of all, the values of the ``cpuinfo_max_freq``, ``cpuinfo_min_freq`` and459``scaling_cur_freq`` attributes are produced by applying a processor-specific460multiplier to the internal P-state representation used by ``intel_pstate``.461Also, the values of the ``scaling_max_freq`` and ``scaling_min_freq``462attributes are capped by the frequency corresponding to the maximum P-state that463the driver is allowed to set.464 465If the ``no_turbo`` `global attribute <no_turbo_attr_>`_ is set, the driver is466not allowed to use turbo P-states, so the maximum value of ``scaling_max_freq``467and ``scaling_min_freq`` is limited to the maximum non-turbo P-state frequency.468Accordingly, setting ``no_turbo`` causes ``scaling_max_freq`` and469``scaling_min_freq`` to go down to that value if they were above it before.470However, the old values of ``scaling_max_freq`` and ``scaling_min_freq`` will be471restored after unsetting ``no_turbo``, unless these attributes have been written472to after ``no_turbo`` was set.473 474If ``no_turbo`` is not set, the maximum possible value of ``scaling_max_freq``475and ``scaling_min_freq`` corresponds to the maximum supported turbo P-state,476which also is the value of ``cpuinfo_max_freq`` in either case.477 478Next, the following policy attributes have special meaning if479``intel_pstate`` works in the `active mode <Active Mode_>`_:480 481``scaling_available_governors``482 List of P-state selection algorithms provided by ``intel_pstate``.483 484``scaling_governor``485 P-state selection algorithm provided by ``intel_pstate`` currently in486 use with the given policy.487 488``scaling_cur_freq``489 Frequency of the average P-state of the CPU represented by the given490 policy for the time interval between the last two invocations of the491 driver's utilization update callback by the CPU scheduler for that CPU.492 493One more policy attribute is present if the HWP feature is enabled in the494processor:495 496``base_frequency``497 Shows the base frequency of the CPU. Any frequency above this will be498 in the turbo frequency range.499 500The meaning of these attributes in the `passive mode <Passive Mode_>`_ is the501same as for other scaling drivers.502 503Additionally, the value of the ``scaling_driver`` attribute for ``intel_pstate``504depends on the operation mode of the driver. Namely, it is either505"intel_pstate" (in the `active mode <Active Mode_>`_) or "intel_cpufreq" (in the506`passive mode <Passive Mode_>`_).507 508Coordination of P-State Limits509------------------------------510 511``intel_pstate`` allows P-state limits to be set in two ways: with the help of512the ``max_perf_pct`` and ``min_perf_pct`` `global attributes513<Global Attributes_>`_ or via the ``scaling_max_freq`` and ``scaling_min_freq``514``CPUFreq`` policy attributes. The coordination between those limits is based515on the following rules, regardless of the current operation mode of the driver:516 517 1. All CPUs are affected by the global limits (that is, none of them can be518 requested to run faster than the global maximum and none of them can be519 requested to run slower than the global minimum).520 521 2. Each individual CPU is affected by its own per-policy limits (that is, it522 cannot be requested to run faster than its own per-policy maximum and it523 cannot be requested to run slower than its own per-policy minimum). The524 effective performance depends on whether the platform supports per core525 P-states, hyper-threading is enabled and on current performance requests526 from other CPUs. When platform doesn't support per core P-states, the527 effective performance can be more than the policy limits set on a CPU, if528 other CPUs are requesting higher performance at that moment. Even with per529 core P-states support, when hyper-threading is enabled, if the sibling CPU530 is requesting higher performance, the other siblings will get higher531 performance than their policy limits.532 533 3. The global and per-policy limits can be set independently.534 535In the `active mode with the HWP feature enabled <Active Mode With HWP_>`_, the536resulting effective values are written into hardware registers whenever the537limits change in order to request its internal P-state selection logic to always538set P-states within these limits. Otherwise, the limits are taken into account539by scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver540every time before setting a new P-state for a CPU.541 542Additionally, if the ``intel_pstate=per_cpu_perf_limits`` command line argument543is passed to the kernel, ``max_perf_pct`` and ``min_perf_pct`` are not exposed544at all and the only way to set the limits is by using the policy attributes.545 546 547Energy vs Performance Hints548---------------------------549 550If the hardware-managed P-states (HWP) is enabled in the processor, additional551attributes, intended to allow user space to help ``intel_pstate`` to adjust the552processor's internal P-state selection logic by focusing it on performance or on553energy-efficiency, or somewhere between the two extremes, are present in every554``CPUFreq`` policy directory in ``sysfs``. They are :555 556``energy_performance_preference``557 Current value of the energy vs performance hint for the given policy558 (or the CPU represented by it).559 560 The hint can be changed by writing to this attribute.561 562``energy_performance_available_preferences``563 List of strings that can be written to the564 ``energy_performance_preference`` attribute.565 566 They represent different energy vs performance hints and should be567 self-explanatory, except that ``default`` represents whatever hint568 value was set by the platform firmware.569 570Strings written to the ``energy_performance_preference`` attribute are571internally translated to integer values written to the processor's572Energy-Performance Preference (EPP) knob (if supported) or its573Energy-Performance Bias (EPB) knob. It is also possible to write a positive574integer value between 0 to 255, if the EPP feature is present. If the EPP575feature is not present, writing integer value to this attribute is not576supported. In this case, user can use the577"/sys/devices/system/cpu/cpu*/power/energy_perf_bias" interface.578 579[Note that tasks may by migrated from one CPU to another by the scheduler's580load-balancing algorithm and if different energy vs performance hints are581set for those CPUs, that may lead to undesirable outcomes. To avoid such582issues it is better to set the same energy vs performance hint for all CPUs583or to pin every task potentially sensitive to them to a specific CPU.]584 585.. _acpi-cpufreq:586 587``intel_pstate`` vs ``acpi-cpufreq``588====================================589 590On the majority of systems supported by ``intel_pstate``, the ACPI tables591provided by the platform firmware contain ``_PSS`` objects returning information592that can be used for CPU performance scaling (refer to the ACPI specification593[3]_ for details on the ``_PSS`` objects and the format of the information594returned by them).595 596The information returned by the ACPI ``_PSS`` objects is used by the597``acpi-cpufreq`` scaling driver. On systems supported by ``intel_pstate``598the ``acpi-cpufreq`` driver uses the same hardware CPU performance scaling599interface, but the set of P-states it can use is limited by the ``_PSS``600output.601 602On those systems each ``_PSS`` object returns a list of P-states supported by603the corresponding CPU which basically is a subset of the P-states range that can604be used by ``intel_pstate`` on the same system, with one exception: the whole605`turbo range <turbo_>`_ is represented by one item in it (the topmost one). By606convention, the frequency returned by ``_PSS`` for that item is greater by 1 MHz607than the frequency of the highest non-turbo P-state listed by it, but the608corresponding P-state representation (following the hardware specification)609returned for it matches the maximum supported turbo P-state (or is the610special value 255 meaning essentially "go as high as you can get").611 612The list of P-states returned by ``_PSS`` is reflected by the table of613available frequencies supplied by ``acpi-cpufreq`` to the ``CPUFreq`` core and614scaling governors and the minimum and maximum supported frequencies reported by615it come from that list as well. In particular, given the special representation616of the turbo range described above, this means that the maximum supported617frequency reported by ``acpi-cpufreq`` is higher by 1 MHz than the frequency618of the highest supported non-turbo P-state listed by ``_PSS`` which, of course,619affects decisions made by the scaling governors, except for ``powersave`` and620``performance``.621 622For example, if a given governor attempts to select a frequency proportional to623estimated CPU load and maps the load of 100% to the maximum supported frequency624(possibly multiplied by a constant), then it will tend to choose P-states below625the turbo threshold if ``acpi-cpufreq`` is used as the scaling driver, because626in that case the turbo range corresponds to a small fraction of the frequency627band it can use (1 MHz vs 1 GHz or more). In consequence, it will only go to628the turbo range for the highest loads and the other loads above 50% that might629benefit from running at turbo frequencies will be given non-turbo P-states630instead.631 632One more issue related to that may appear on systems supporting the633`Configurable TDP feature <turbo_>`_ allowing the platform firmware to set the634turbo threshold. Namely, if that is not coordinated with the lists of P-states635returned by ``_PSS`` properly, there may be more than one item corresponding to636a turbo P-state in those lists and there may be a problem with avoiding the637turbo range (if desirable or necessary). Usually, to avoid using turbo638P-states overall, ``acpi-cpufreq`` simply avoids using the topmost state listed639by ``_PSS``, but that is not sufficient when there are other turbo P-states in640the list returned by it.641 642Apart from the above, ``acpi-cpufreq`` works like ``intel_pstate`` in the643`passive mode <Passive Mode_>`_, except that the number of P-states it can set644is limited to the ones listed by the ACPI ``_PSS`` objects.645 646 647Kernel Command Line Options for ``intel_pstate``648================================================649 650Several kernel command line options can be used to pass early-configuration-time651parameters to ``intel_pstate`` in order to enforce specific behavior of it. All652of them have to be prepended with the ``intel_pstate=`` prefix.653 654``disable``655 Do not register ``intel_pstate`` as the scaling driver even if the656 processor is supported by it.657 658``active``659 Register ``intel_pstate`` in the `active mode <Active Mode_>`_ to start660 with.661 662``passive``663 Register ``intel_pstate`` in the `passive mode <Passive Mode_>`_ to664 start with.665 666``force``667 Register ``intel_pstate`` as the scaling driver instead of668 ``acpi-cpufreq`` even if the latter is preferred on the given system.669 670 This may prevent some platform features (such as thermal controls and671 power capping) that rely on the availability of ACPI P-states672 information from functioning as expected, so it should be used with673 caution.674 675 This option does not work with processors that are not supported by676 ``intel_pstate`` and on platforms where the ``pcc-cpufreq`` scaling677 driver is used instead of ``acpi-cpufreq``.678 679``no_hwp``680 Do not enable the hardware-managed P-states (HWP) feature even if it is681 supported by the processor.682 683``hwp_only``684 Register ``intel_pstate`` as the scaling driver only if the685 hardware-managed P-states (HWP) feature is supported by the processor.686 687``support_acpi_ppc``688 Take ACPI ``_PPC`` performance limits into account.689 690 If the preferred power management profile in the FADT (Fixed ACPI691 Description Table) is set to "Enterprise Server" or "Performance692 Server", the ACPI ``_PPC`` limits are taken into account by default693 and this option has no effect.694 695``per_cpu_perf_limits``696 Use per-logical-CPU P-State limits (see `Coordination of P-state697 Limits`_ for details).698 699 700Diagnostics and Tuning701======================702 703Trace Events704------------705 706There are two static trace events that can be used for ``intel_pstate``707diagnostics. One of them is the ``cpu_frequency`` trace event generally used708by ``CPUFreq``, and the other one is the ``pstate_sample`` trace event specific709to ``intel_pstate``. Both of them are triggered by ``intel_pstate`` only if710it works in the `active mode <Active Mode_>`_.711 712The following sequence of shell commands can be used to enable them and see713their output (if the kernel is generally configured to support event tracing)::714 715 # cd /sys/kernel/tracing/716 # echo 1 > events/power/pstate_sample/enable717 # echo 1 > events/power/cpu_frequency/enable718 # cat trace719 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=2474476720 cat-5235 [002] ..s. 1177.681723: cpu_frequency: state=2900000 cpu_id=2721 722If ``intel_pstate`` works in the `passive mode <Passive Mode_>`_, the723``cpu_frequency`` trace event will be triggered either by the ``schedutil``724scaling governor (for the policies it is attached to), or by the ``CPUFreq``725core (for the policies with other scaling governors).726 727``ftrace``728----------729 730The ``ftrace`` interface can be used for low-level diagnostics of731``intel_pstate``. For example, to check how often the function to set a732P-state is called, the ``ftrace`` filter can be set to733:c:func:`intel_pstate_set_pstate`::734 735 # cd /sys/kernel/tracing/736 # cat available_filter_functions | grep -i pstate737 intel_pstate_set_pstate738 intel_pstate_cpu_init739 ...740 # echo intel_pstate_set_pstate > set_ftrace_filter741 # echo function > current_tracer742 # cat trace | head -15743 # tracer: function744 #745 # entries-in-buffer/entries-written: 80/80 #P:4746 #747 # _-----=> irqs-off748 # / _----=> need-resched749 # | / _---=> hardirq/softirq750 # || / _--=> preempt-depth751 # ||| / delay752 # TASK-PID CPU# |||| TIMESTAMP FUNCTION753 # | | | |||| | |754 Xorg-3129 [000] ..s. 2537.644844: intel_pstate_set_pstate <-intel_pstate_timer_func755 gnome-terminal--4510 [002] ..s. 2537.649844: intel_pstate_set_pstate <-intel_pstate_timer_func756 gnome-shell-3409 [001] ..s. 2537.650850: intel_pstate_set_pstate <-intel_pstate_timer_func757 <idle>-0 [000] ..s. 2537.654843: intel_pstate_set_pstate <-intel_pstate_timer_func758 759 760References761==========762 763.. [1] Kristen Accardi, *Balancing Power and Performance in the Linux Kernel*,764 https://events.static.linuxfound.org/sites/events/files/slides/LinuxConEurope_2015.pdf765 766.. [2] *Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3: System Programming Guide*,767 https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-system-programming-manual-325384.html768 769.. [3] *Advanced Configuration and Power Interface Specification*,770 https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf771