1=============================================== 2``intel_pstate`` CPU Performance Scaling Driver 3=============================================== 4 5:: 6 7 Copyright (c) 2017 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com> 8 9 10General Information 11=================== 12 13``intel_pstate`` is a part of the 14:doc:`CPU performance scaling subsystem <cpufreq>` in the Linux kernel 15(``CPUFreq``). It is a scaling driver for the Sandy Bridge and later 16generations of Intel processors. Note, however, that some of those processors 17may not be supported. [To understand ``intel_pstate`` it is necessary to know 18how ``CPUFreq`` works in general, so this is the time to read :doc:`cpufreq` if 19you have not done that yet.] 20 21For the processors supported by ``intel_pstate``, the P-state concept is broader 22than just an operating frequency or an operating performance point (see the 23`LinuxCon Europe 2015 presentation by Kristen Accardi <LCEU2015_>`_ for more 24information about that). For this reason, the representation of P-states used 25by ``intel_pstate`` internally follows the hardware specification (for details 26refer to `Intel® 64 and IA-32 Architectures Software Developer’s Manual 27Volume 3: System Programming Guide <SDM_>`_). However, the ``CPUFreq`` core 28uses frequencies for identifying operating performance points of CPUs and 29frequencies are involved in the user space interface exposed by it, so 30``intel_pstate`` maps its internal representation of P-states to frequencies too 31(fortunately, that mapping is unambiguous). At the same time, it would not be 32practical for ``intel_pstate`` to supply the ``CPUFreq`` core with a table of 33available frequencies due to the possible size of it, so the driver does not do 34that. Some functionality of the core is limited by that. 35 36Since the hardware P-state selection interface used by ``intel_pstate`` is 37available at the logical CPU level, the driver always works with individual 38CPUs. Consequently, if ``intel_pstate`` is in use, every ``CPUFreq`` policy 39object corresponds to one logical CPU and ``CPUFreq`` policies are effectively 40equivalent to CPUs. In particular, this means that they become "inactive" every 41time the corresponding CPU is taken offline and need to be re-initialized when 42it goes back online. 43 44``intel_pstate`` is not modular, so it cannot be unloaded, which means that the 45only way to pass early-configuration-time parameters to it is via the kernel 46command line. However, its configuration can be adjusted via ``sysfs`` to a 47great extent. In some configurations it even is possible to unregister it via 48``sysfs`` which allows another ``CPUFreq`` scaling driver to be loaded and 49registered (see `below <status_attr_>`_). 50 51 52Operation Modes 53=============== 54 55``intel_pstate`` can operate in three different modes: in the active mode with 56or without hardware-managed P-states support and in the passive mode. Which of 57them will be in effect depends on what kernel command line options are used and 58on the capabilities of the processor. 59 60Active Mode 61----------- 62 63This is the default operation mode of ``intel_pstate``. If it works in this 64mode, the ``scaling_driver`` policy attribute in ``sysfs`` for all ``CPUFreq`` 65policies contains the string "intel_pstate". 66 67In this mode the driver bypasses the scaling governors layer of ``CPUFreq`` and 68provides its own scaling algorithms for P-state selection. Those algorithms 69can be applied to ``CPUFreq`` policies in the same way as generic scaling 70governors (that is, through the ``scaling_governor`` policy attribute in 71``sysfs``). [Note that different P-state selection algorithms may be chosen for 72different policies, but that is not recommended.] 73 74They are not generic scaling governors, but their names are the same as the 75names of some of those governors. Moreover, confusingly enough, they generally 76do not work in the same way as the generic governors they share the names with. 77For example, the ``powersave`` P-state selection algorithm provided by 78``intel_pstate`` is not a counterpart of the generic ``powersave`` governor 79(roughly, it corresponds to the ``schedutil`` and ``ondemand`` governors). 80 81There are two P-state selection algorithms provided by ``intel_pstate`` in the 82active mode: ``powersave`` and ``performance``. The way they both operate 83depends on whether or not the hardware-managed P-states (HWP) feature has been 84enabled in the processor and possibly on the processor model. 85 86Which of the P-state selection algorithms is used by default depends on the 87:c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option. 88Namely, if that option is set, the ``performance`` algorithm will be used by 89default, and the other one will be used by default if it is not set. 90 91Active Mode With HWP 92~~~~~~~~~~~~~~~~~~~~ 93 94If the processor supports the HWP feature, it will be enabled during the 95processor initialization and cannot be disabled after that. It is possible 96to avoid enabling it by passing the ``intel_pstate=no_hwp`` argument to the 97kernel in the command line. 98 99If the HWP feature has been enabled, ``intel_pstate`` relies on the processor to 100select P-states by itself, but still it can give hints to the processor's 101internal P-state selection logic. What those hints are depends on which P-state 102selection algorithm has been applied to the given policy (or to the CPU it 103corresponds to). 104 105Even though the P-state selection is carried out by the processor automatically, 106``intel_pstate`` registers utilization update callbacks with the CPU scheduler 107in this mode. However, they are not used for running a P-state selection 108algorithm, but for periodic updates of the current CPU frequency information to 109be made available from the ``scaling_cur_freq`` policy attribute in ``sysfs``. 110 111HWP + ``performance`` 112..................... 113 114In this configuration ``intel_pstate`` will write 0 to the processor's 115Energy-Performance Preference (EPP) knob (if supported) or its 116Energy-Performance Bias (EPB) knob (otherwise), which means that the processor's 117internal P-state selection logic is expected to focus entirely on performance. 118 119This will override the EPP/EPB setting coming from the ``sysfs`` interface 120(see `Energy vs Performance Hints`_ below). 121 122Also, in this configuration the range of P-states available to the processor's 123internal P-state selection logic is always restricted to the upper boundary 124(that is, the maximum P-state that the driver is allowed to use). 125 126HWP + ``powersave`` 127................... 128 129In this configuration ``intel_pstate`` will set the processor's 130Energy-Performance Preference (EPP) knob (if supported) or its 131Energy-Performance Bias (EPB) knob (otherwise) to whatever value it was 132previously set to via ``sysfs`` (or whatever default value it was 133set to by the platform firmware). This usually causes the processor's 134internal P-state selection logic to be less performance-focused. 135 136Active Mode Without HWP 137~~~~~~~~~~~~~~~~~~~~~~~ 138 139This is the default operation mode for processors that do not support the HWP 140feature. It also is used by default with the ``intel_pstate=no_hwp`` argument 141in the kernel command line. However, in this mode ``intel_pstate`` may refuse 142to work with the given processor if it does not recognize it. [Note that 143``intel_pstate`` will never refuse to work with any processor with the HWP 144feature enabled.] 145 146In this mode ``intel_pstate`` registers utilization update callbacks with the 147CPU scheduler in order to run a P-state selection algorithm, either 148``powersave`` or ``performance``, depending on the ``scaling_governor`` policy 149setting in ``sysfs``. The current CPU frequency information to be made 150available from the ``scaling_cur_freq`` policy attribute in ``sysfs`` is 151periodically updated by those utilization update callbacks too. 152 153``performance`` 154............... 155 156Without HWP, this P-state selection algorithm is always the same regardless of 157the processor model and platform configuration. 158 159It selects the maximum P-state it is allowed to use, subject to limits set via 160``sysfs``, every time the driver configuration for the given CPU is updated 161(e.g. via ``sysfs``). 162 163This is the default P-state selection algorithm if the 164:c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option 165is set. 166 167``powersave`` 168............. 169 170Without HWP, this P-state selection algorithm is similar to the algorithm 171implemented by the generic ``schedutil`` scaling governor except that the 172utilization metric used by it is based on numbers coming from feedback 173registers of the CPU. It generally selects P-states proportional to the 174current CPU utilization. 175 176This algorithm is run by the driver's utilization update callback for the 177given CPU when it is invoked by the CPU scheduler, but not more often than 178every 10 ms. Like in the ``performance`` case, the hardware configuration 179is not touched if the new P-state turns out to be the same as the current 180one. 181 182This is the default P-state selection algorithm if the 183:c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option 184is not set. 185 186Passive Mode 187------------ 188 189This mode is used if the ``intel_pstate=passive`` argument is passed to the 190kernel in the command line (it implies the ``intel_pstate=no_hwp`` setting too). 191Like in the active mode without HWP support, in this mode ``intel_pstate`` may 192refuse to work with the given processor if it does not recognize it. 193 194If the driver works in this mode, the ``scaling_driver`` policy attribute in 195``sysfs`` for all ``CPUFreq`` policies contains the string "intel_cpufreq". 196Then, the driver behaves like a regular ``CPUFreq`` scaling driver. That is, 197it is invoked by generic scaling governors when necessary to talk to the 198hardware in order to change the P-state of a CPU (in particular, the 199``schedutil`` governor can invoke it directly from scheduler context). 200 201While in this mode, ``intel_pstate`` can be used with all of the (generic) 202scaling governors listed by the ``scaling_available_governors`` policy attribute 203in ``sysfs`` (and the P-state selection algorithms described above are not 204used). Then, it is responsible for the configuration of policy objects 205corresponding to CPUs and provides the ``CPUFreq`` core (and the scaling 206governors attached to the policy objects) with accurate information on the 207maximum and minimum operating frequencies supported by the hardware (including 208the so-called "turbo" frequency ranges). In other words, in the passive mode 209the entire range of available P-states is exposed by ``intel_pstate`` to the 210``CPUFreq`` core. However, in this mode the driver does not register 211utilization update callbacks with the CPU scheduler and the ``scaling_cur_freq`` 212information comes from the ``CPUFreq`` core (and is the last frequency selected 213by the current scaling governor for the given policy). 214 215 216.. _turbo: 217 218Turbo P-states Support 219====================== 220 221In the majority of cases, the entire range of P-states available to 222``intel_pstate`` can be divided into two sub-ranges that correspond to 223different types of processor behavior, above and below a boundary that 224will be referred to as the "turbo threshold" in what follows. 225 226The P-states above the turbo threshold are referred to as "turbo P-states" and 227the whole sub-range of P-states they belong to is referred to as the "turbo 228range". These names are related to the Turbo Boost technology allowing a 229multicore processor to opportunistically increase the P-state of one or more 230cores if there is enough power to do that and if that is not going to cause the 231thermal envelope of the processor package to be exceeded. 232 233Specifically, if software sets the P-state of a CPU core within the turbo range 234(that is, above the turbo threshold), the processor is permitted to take over 235performance scaling control for that core and put it into turbo P-states of its 236choice going forward. However, that permission is interpreted differently by 237different processor generations. Namely, the Sandy Bridge generation of 238processors will never use any P-states above the last one set by software for 239the given core, even if it is within the turbo range, whereas all of the later 240processor generations will take it as a license to use any P-states from the 241turbo range, even above the one set by software. In other words, on those 242processors setting any P-state from the turbo range will enable the processor 243to put the given core into all turbo P-states up to and including the maximum 244supported one as it sees fit. 245 246One important property of turbo P-states is that they are not sustainable. More 247precisely, there is no guarantee that any CPUs will be able to stay in any of 248those states indefinitely, because the power distribution within the processor 249package may change over time or the thermal envelope it was designed for might 250be exceeded if a turbo P-state was used for too long. 251 252In turn, the P-states below the turbo threshold generally are sustainable. In 253fact, if one of them is set by software, the processor is not expected to change 254it to a lower one unless in a thermal stress or a power limit violation 255situation (a higher P-state may still be used if it is set for another CPU in 256the same package at the same time, for example). 257 258Some processors allow multiple cores to be in turbo P-states at the same time, 259but the maximum P-state that can be set for them generally depends on the number 260of cores running concurrently. The maximum turbo P-state that can be set for 3 261cores at the same time usually is lower than the analogous maximum P-state for 2622 cores, which in turn usually is lower than the maximum turbo P-state that can 263be set for 1 core. The one-core maximum turbo P-state is thus the maximum 264supported one overall. 265 266The maximum supported turbo P-state, the turbo threshold (the maximum supported 267non-turbo P-state) and the minimum supported P-state are specific to the 268processor model and can be determined by reading the processor's model-specific 269registers (MSRs). Moreover, some processors support the Configurable TDP 270(Thermal Design Power) feature and, when that feature is enabled, the turbo 271threshold effectively becomes a configurable value that can be set by the 272platform firmware. 273 274Unlike ``_PSS`` objects in the ACPI tables, ``intel_pstate`` always exposes 275the entire range of available P-states, including the whole turbo range, to the 276``CPUFreq`` core and (in the passive mode) to generic scaling governors. This 277generally causes turbo P-states to be set more often when ``intel_pstate`` is 278used relative to ACPI-based CPU performance scaling (see `below <acpi-cpufreq_>`_ 279for more information). 280 281Moreover, since ``intel_pstate`` always knows what the real turbo threshold is 282(even if the Configurable TDP feature is enabled in the processor), its 283``no_turbo`` attribute in ``sysfs`` (described `below <no_turbo_attr_>`_) should 284work as expected in all cases (that is, if set to disable turbo P-states, it 285always should prevent ``intel_pstate`` from using them). 286 287 288Processor Support 289================= 290 291To handle a given processor ``intel_pstate`` requires a number of different 292pieces of information on it to be known, including: 293 294 * The minimum supported P-state. 295 296 * The maximum supported `non-turbo P-state <turbo_>`_. 297 298 * Whether or not turbo P-states are supported at all. 299 300 * The maximum supported `one-core turbo P-state <turbo_>`_ (if turbo P-states 301 are supported). 302 303 * The scaling formula to translate the driver's internal representation 304 of P-states into frequencies and the other way around. 305 306Generally, ways to obtain that information are specific to the processor model 307or family. Although it often is possible to obtain all of it from the processor 308itself (using model-specific registers), there are cases in which hardware 309manuals need to be consulted to get to it too. 310 311For this reason, there is a list of supported processors in ``intel_pstate`` and 312the driver initialization will fail if the detected processor is not in that 313list, unless it supports the `HWP feature <Active Mode_>`_. [The interface to 314obtain all of the information listed above is the same for all of the processors 315supporting the HWP feature, which is why they all are supported by 316``intel_pstate``.] 317 318 319User Space Interface in ``sysfs`` 320================================= 321 322Global Attributes 323----------------- 324 325``intel_pstate`` exposes several global attributes (files) in ``sysfs`` to 326control its functionality at the system level. They are located in the 327``/sys/devices/system/cpu/intel_pstate/`` directory and affect all CPUs. 328 329Some of them are not present if the ``intel_pstate=per_cpu_perf_limits`` 330argument is passed to the kernel in the command line. 331 332``max_perf_pct`` 333 Maximum P-state the driver is allowed to set in percent of the 334 maximum supported performance level (the highest supported `turbo 335 P-state <turbo_>`_). 336 337 This attribute will not be exposed if the 338 ``intel_pstate=per_cpu_perf_limits`` argument is present in the kernel 339 command line. 340 341``min_perf_pct`` 342 Minimum P-state the driver is allowed to set in percent of the 343 maximum supported performance level (the highest supported `turbo 344 P-state <turbo_>`_). 345 346 This attribute will not be exposed if the 347 ``intel_pstate=per_cpu_perf_limits`` argument is present in the kernel 348 command line. 349 350``num_pstates`` 351 Number of P-states supported by the processor (between 0 and 255 352 inclusive) including both turbo and non-turbo P-states (see 353 `Turbo P-states Support`_). 354 355 The value of this attribute is not affected by the ``no_turbo`` 356 setting described `below <no_turbo_attr_>`_. 357 358 This attribute is read-only. 359 360``turbo_pct`` 361 Ratio of the `turbo range <turbo_>`_ size to the size of the entire 362 range of supported P-states, in percent. 363 364 This attribute is read-only. 365 366.. _no_turbo_attr: 367 368``no_turbo`` 369 If set (equal to 1), the driver is not allowed to set any turbo P-states 370 (see `Turbo P-states Support`_). If unset (equalt to 0, which is the 371 default), turbo P-states can be set by the driver. 372 [Note that ``intel_pstate`` does not support the general ``boost`` 373 attribute (supported by some other scaling drivers) which is replaced 374 by this one.] 375 376 This attrubute does not affect the maximum supported frequency value 377 supplied to the ``CPUFreq`` core and exposed via the policy interface, 378 but it affects the maximum possible value of per-policy P-state limits 379 (see `Interpretation of Policy Attributes`_ below for details). 380 381``hwp_dynamic_boost`` 382 This attribute is only present if ``intel_pstate`` works in the 383 `active mode with the HWP feature enabled <Active Mode With HWP_>`_ in 384 the processor. If set (equal to 1), it causes the minimum P-state limit 385 to be increased dynamically for a short time whenever a task previously 386 waiting on I/O is selected to run on a given logical CPU (the purpose 387 of this mechanism is to improve performance). 388 389 This setting has no effect on logical CPUs whose minimum P-state limit 390 is directly set to the highest non-turbo P-state or above it. 391 392.. _status_attr: 393 394``status`` 395 Operation mode of the driver: "active", "passive" or "off". 396 397 "active" 398 The driver is functional and in the `active mode 399 <Active Mode_>`_. 400 401 "passive" 402 The driver is functional and in the `passive mode 403 <Passive Mode_>`_. 404 405 "off" 406 The driver is not functional (it is not registered as a scaling 407 driver with the ``CPUFreq`` core). 408 409 This attribute can be written to in order to change the driver's 410 operation mode or to unregister it. The string written to it must be 411 one of the possible values of it and, if successful, the write will 412 cause the driver to switch over to the operation mode represented by 413 that string - or to be unregistered in the "off" case. [Actually, 414 switching over from the active mode to the passive mode or the other 415 way around causes the driver to be unregistered and registered again 416 with a different set of callbacks, so all of its settings (the global 417 as well as the per-policy ones) are then reset to their default 418 values, possibly depending on the target operation mode.] 419 420 That only is supported in some configurations, though (for example, if 421 the `HWP feature is enabled in the processor <Active Mode With HWP_>`_, 422 the operation mode of the driver cannot be changed), and if it is not 423 supported in the current configuration, writes to this attribute will 424 fail with an appropriate error. 425 426Interpretation of Policy Attributes 427----------------------------------- 428 429The interpretation of some ``CPUFreq`` policy attributes described in 430:doc:`cpufreq` is special with ``intel_pstate`` as the current scaling driver 431and it generally depends on the driver's `operation mode <Operation Modes_>`_. 432 433First of all, the values of the ``cpuinfo_max_freq``, ``cpuinfo_min_freq`` and 434``scaling_cur_freq`` attributes are produced by applying a processor-specific 435multiplier to the internal P-state representation used by ``intel_pstate``. 436Also, the values of the ``scaling_max_freq`` and ``scaling_min_freq`` 437attributes are capped by the frequency corresponding to the maximum P-state that 438the driver is allowed to set. 439 440If the ``no_turbo`` `global attribute <no_turbo_attr_>`_ is set, the driver is 441not allowed to use turbo P-states, so the maximum value of ``scaling_max_freq`` 442and ``scaling_min_freq`` is limited to the maximum non-turbo P-state frequency. 443Accordingly, setting ``no_turbo`` causes ``scaling_max_freq`` and 444``scaling_min_freq`` to go down to that value if they were above it before. 445However, the old values of ``scaling_max_freq`` and ``scaling_min_freq`` will be 446restored after unsetting ``no_turbo``, unless these attributes have been written 447to after ``no_turbo`` was set. 448 449If ``no_turbo`` is not set, the maximum possible value of ``scaling_max_freq`` 450and ``scaling_min_freq`` corresponds to the maximum supported turbo P-state, 451which also is the value of ``cpuinfo_max_freq`` in either case. 452 453Next, the following policy attributes have special meaning if 454``intel_pstate`` works in the `active mode <Active Mode_>`_: 455 456``scaling_available_governors`` 457 List of P-state selection algorithms provided by ``intel_pstate``. 458 459``scaling_governor`` 460 P-state selection algorithm provided by ``intel_pstate`` currently in 461 use with the given policy. 462 463``scaling_cur_freq`` 464 Frequency of the average P-state of the CPU represented by the given 465 policy for the time interval between the last two invocations of the 466 driver's utilization update callback by the CPU scheduler for that CPU. 467 468The meaning of these attributes in the `passive mode <Passive Mode_>`_ is the 469same as for other scaling drivers. 470 471Additionally, the value of the ``scaling_driver`` attribute for ``intel_pstate`` 472depends on the operation mode of the driver. Namely, it is either 473"intel_pstate" (in the `active mode <Active Mode_>`_) or "intel_cpufreq" (in the 474`passive mode <Passive Mode_>`_). 475 476Coordination of P-State Limits 477------------------------------ 478 479``intel_pstate`` allows P-state limits to be set in two ways: with the help of 480the ``max_perf_pct`` and ``min_perf_pct`` `global attributes 481<Global Attributes_>`_ or via the ``scaling_max_freq`` and ``scaling_min_freq`` 482``CPUFreq`` policy attributes. The coordination between those limits is based 483on the following rules, regardless of the current operation mode of the driver: 484 485 1. All CPUs are affected by the global limits (that is, none of them can be 486 requested to run faster than the global maximum and none of them can be 487 requested to run slower than the global minimum). 488 489 2. Each individual CPU is affected by its own per-policy limits (that is, it 490 cannot be requested to run faster than its own per-policy maximum and it 491 cannot be requested to run slower than its own per-policy minimum). 492 493 3. The global and per-policy limits can be set independently. 494 495If the `HWP feature is enabled in the processor <Active Mode With HWP_>`_, the 496resulting effective values are written into its registers whenever the limits 497change in order to request its internal P-state selection logic to always set 498P-states within these limits. Otherwise, the limits are taken into account by 499scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver 500every time before setting a new P-state for a CPU. 501 502Additionally, if the ``intel_pstate=per_cpu_perf_limits`` command line argument 503is passed to the kernel, ``max_perf_pct`` and ``min_perf_pct`` are not exposed 504at all and the only way to set the limits is by using the policy attributes. 505 506 507Energy vs Performance Hints 508--------------------------- 509 510If ``intel_pstate`` works in the `active mode with the HWP feature enabled 511<Active Mode With HWP_>`_ in the processor, additional attributes are present 512in every ``CPUFreq`` policy directory in ``sysfs``. They are intended to allow 513user space to help ``intel_pstate`` to adjust the processor's internal P-state 514selection logic by focusing it on performance or on energy-efficiency, or 515somewhere between the two extremes: 516 517``energy_performance_preference`` 518 Current value of the energy vs performance hint for the given policy 519 (or the CPU represented by it). 520 521 The hint can be changed by writing to this attribute. 522 523``energy_performance_available_preferences`` 524 List of strings that can be written to the 525 ``energy_performance_preference`` attribute. 526 527 They represent different energy vs performance hints and should be 528 self-explanatory, except that ``default`` represents whatever hint 529 value was set by the platform firmware. 530 531Strings written to the ``energy_performance_preference`` attribute are 532internally translated to integer values written to the processor's 533Energy-Performance Preference (EPP) knob (if supported) or its 534Energy-Performance Bias (EPB) knob. 535 536[Note that tasks may by migrated from one CPU to another by the scheduler's 537load-balancing algorithm and if different energy vs performance hints are 538set for those CPUs, that may lead to undesirable outcomes. To avoid such 539issues it is better to set the same energy vs performance hint for all CPUs 540or to pin every task potentially sensitive to them to a specific CPU.] 541 542.. _acpi-cpufreq: 543 544``intel_pstate`` vs ``acpi-cpufreq`` 545==================================== 546 547On the majority of systems supported by ``intel_pstate``, the ACPI tables 548provided by the platform firmware contain ``_PSS`` objects returning information 549that can be used for CPU performance scaling (refer to the `ACPI specification`_ 550for details on the ``_PSS`` objects and the format of the information returned 551by them). 552 553The information returned by the ACPI ``_PSS`` objects is used by the 554``acpi-cpufreq`` scaling driver. On systems supported by ``intel_pstate`` 555the ``acpi-cpufreq`` driver uses the same hardware CPU performance scaling 556interface, but the set of P-states it can use is limited by the ``_PSS`` 557output. 558 559On those systems each ``_PSS`` object returns a list of P-states supported by 560the corresponding CPU which basically is a subset of the P-states range that can 561be used by ``intel_pstate`` on the same system, with one exception: the whole 562`turbo range <turbo_>`_ is represented by one item in it (the topmost one). By 563convention, the frequency returned by ``_PSS`` for that item is greater by 1 MHz 564than the frequency of the highest non-turbo P-state listed by it, but the 565corresponding P-state representation (following the hardware specification) 566returned for it matches the maximum supported turbo P-state (or is the 567special value 255 meaning essentially "go as high as you can get"). 568 569The list of P-states returned by ``_PSS`` is reflected by the table of 570available frequencies supplied by ``acpi-cpufreq`` to the ``CPUFreq`` core and 571scaling governors and the minimum and maximum supported frequencies reported by 572it come from that list as well. In particular, given the special representation 573of the turbo range described above, this means that the maximum supported 574frequency reported by ``acpi-cpufreq`` is higher by 1 MHz than the frequency 575of the highest supported non-turbo P-state listed by ``_PSS`` which, of course, 576affects decisions made by the scaling governors, except for ``powersave`` and 577``performance``. 578 579For example, if a given governor attempts to select a frequency proportional to 580estimated CPU load and maps the load of 100% to the maximum supported frequency 581(possibly multiplied by a constant), then it will tend to choose P-states below 582the turbo threshold if ``acpi-cpufreq`` is used as the scaling driver, because 583in that case the turbo range corresponds to a small fraction of the frequency 584band it can use (1 MHz vs 1 GHz or more). In consequence, it will only go to 585the turbo range for the highest loads and the other loads above 50% that might 586benefit from running at turbo frequencies will be given non-turbo P-states 587instead. 588 589One more issue related to that may appear on systems supporting the 590`Configurable TDP feature <turbo_>`_ allowing the platform firmware to set the 591turbo threshold. Namely, if that is not coordinated with the lists of P-states 592returned by ``_PSS`` properly, there may be more than one item corresponding to 593a turbo P-state in those lists and there may be a problem with avoiding the 594turbo range (if desirable or necessary). Usually, to avoid using turbo 595P-states overall, ``acpi-cpufreq`` simply avoids using the topmost state listed 596by ``_PSS``, but that is not sufficient when there are other turbo P-states in 597the list returned by it. 598 599Apart from the above, ``acpi-cpufreq`` works like ``intel_pstate`` in the 600`passive mode <Passive Mode_>`_, except that the number of P-states it can set 601is limited to the ones listed by the ACPI ``_PSS`` objects. 602 603 604Kernel Command Line Options for ``intel_pstate`` 605================================================ 606 607Several kernel command line options can be used to pass early-configuration-time 608parameters to ``intel_pstate`` in order to enforce specific behavior of it. All 609of them have to be prepended with the ``intel_pstate=`` prefix. 610 611``disable`` 612 Do not register ``intel_pstate`` as the scaling driver even if the 613 processor is supported by it. 614 615``passive`` 616 Register ``intel_pstate`` in the `passive mode <Passive Mode_>`_ to 617 start with. 618 619 This option implies the ``no_hwp`` one described below. 620 621``force`` 622 Register ``intel_pstate`` as the scaling driver instead of 623 ``acpi-cpufreq`` even if the latter is preferred on the given system. 624 625 This may prevent some platform features (such as thermal controls and 626 power capping) that rely on the availability of ACPI P-states 627 information from functioning as expected, so it should be used with 628 caution. 629 630 This option does not work with processors that are not supported by 631 ``intel_pstate`` and on platforms where the ``pcc-cpufreq`` scaling 632 driver is used instead of ``acpi-cpufreq``. 633 634``no_hwp`` 635 Do not enable the `hardware-managed P-states (HWP) feature 636 <Active Mode With HWP_>`_ even if it is supported by the processor. 637 638``hwp_only`` 639 Register ``intel_pstate`` as the scaling driver only if the 640 `hardware-managed P-states (HWP) feature <Active Mode With HWP_>`_ is 641 supported by the processor. 642 643``support_acpi_ppc`` 644 Take ACPI ``_PPC`` performance limits into account. 645 646 If the preferred power management profile in the FADT (Fixed ACPI 647 Description Table) is set to "Enterprise Server" or "Performance 648 Server", the ACPI ``_PPC`` limits are taken into account by default 649 and this option has no effect. 650 651``per_cpu_perf_limits`` 652 Use per-logical-CPU P-State limits (see `Coordination of P-state 653 Limits`_ for details). 654 655 656Diagnostics and Tuning 657====================== 658 659Trace Events 660------------ 661 662There are two static trace events that can be used for ``intel_pstate`` 663diagnostics. One of them is the ``cpu_frequency`` trace event generally used 664by ``CPUFreq``, and the other one is the ``pstate_sample`` trace event specific 665to ``intel_pstate``. Both of them are triggered by ``intel_pstate`` only if 666it works in the `active mode <Active Mode_>`_. 667 668The following sequence of shell commands can be used to enable them and see 669their output (if the kernel is generally configured to support event tracing):: 670 671 # cd /sys/kernel/debug/tracing/ 672 # echo 1 > events/power/pstate_sample/enable 673 # echo 1 > events/power/cpu_frequency/enable 674 # cat trace 675 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 676 cat-5235 [002] ..s. 1177.681723: cpu_frequency: state=2900000 cpu_id=2 677 678If ``intel_pstate`` works in the `passive mode <Passive Mode_>`_, the 679``cpu_frequency`` trace event will be triggered either by the ``schedutil`` 680scaling governor (for the policies it is attached to), or by the ``CPUFreq`` 681core (for the policies with other scaling governors). 682 683``ftrace`` 684---------- 685 686The ``ftrace`` interface can be used for low-level diagnostics of 687``intel_pstate``. For example, to check how often the function to set a 688P-state is called, the ``ftrace`` filter can be set to to 689:c:func:`intel_pstate_set_pstate`:: 690 691 # cd /sys/kernel/debug/tracing/ 692 # cat available_filter_functions | grep -i pstate 693 intel_pstate_set_pstate 694 intel_pstate_cpu_init 695 ... 696 # echo intel_pstate_set_pstate > set_ftrace_filter 697 # echo function > current_tracer 698 # cat trace | head -15 699 # tracer: function 700 # 701 # entries-in-buffer/entries-written: 80/80 #P:4 702 # 703 # _-----=> irqs-off 704 # / _----=> need-resched 705 # | / _---=> hardirq/softirq 706 # || / _--=> preempt-depth 707 # ||| / delay 708 # TASK-PID CPU# |||| TIMESTAMP FUNCTION 709 # | | | |||| | | 710 Xorg-3129 [000] ..s. 2537.644844: intel_pstate_set_pstate <-intel_pstate_timer_func 711 gnome-terminal--4510 [002] ..s. 2537.649844: intel_pstate_set_pstate <-intel_pstate_timer_func 712 gnome-shell-3409 [001] ..s. 2537.650850: intel_pstate_set_pstate <-intel_pstate_timer_func 713 <idle>-0 [000] ..s. 2537.654843: intel_pstate_set_pstate <-intel_pstate_timer_func 714 715 716.. _LCEU2015: http://events.linuxfoundation.org/sites/events/files/slides/LinuxConEurope_2015.pdf 717.. _SDM: http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-system-programming-manual-325384.html 718.. _ACPI specification: http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf 719