744 lines
35 KiB
ReStructuredText
744 lines
35 KiB
ReStructuredText
|
.. SPDX-License-Identifier: GPL-2.0
|
|||
|
|
.. include:: <isonum.txt>
|
|||
|
|
|
|||
|
|
===============================================
|
|||
|
|
``intel_pstate`` CPU Performance Scaling Driver
|
|||
|
|
===============================================
|
|||
|
|
|
|||
|
|
:Copyright: |copy| 2017 Intel Corporation
|
|||
|
|
|
|||
|
|
:Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|||
|
|
|
|||
|
|
|
|||
|
|
General Information
|
|||
|
|
===================
|
|||
|
|
|
|||
|
|
``intel_pstate`` is a part of the
|
|||
|
|
:doc:`CPU performance scaling subsystem <cpufreq>` in the Linux kernel
|
|||
|
|
(``CPUFreq``). It is a scaling driver for the Sandy Bridge and later
|
|||
|
|
generations of Intel processors. Note, however, that some of those processors
|
|||
|
|
may not be supported. [To understand ``intel_pstate`` it is necessary to know
|
|||
|
|
how ``CPUFreq`` works in general, so this is the time to read :doc:`cpufreq` if
|
|||
|
|
you have not done that yet.]
|
|||
|
|
|
|||
|
|
For the processors supported by ``intel_pstate``, the P-state concept is broader
|
|||
|
|
than just an operating frequency or an operating performance point (see the
|
|||
|
|
LinuxCon Europe 2015 presentation by Kristen Accardi [1]_ for more
|
|||
|
|
information about that). For this reason, the representation of P-states used
|
|||
|
|
by ``intel_pstate`` internally follows the hardware specification (for details
|
|||
|
|
refer to Intel Software Developer’s Manual [2]_). However, the ``CPUFreq`` core
|
|||
|
|
uses frequencies for identifying operating performance points of CPUs and
|
|||
|
|
frequencies are involved in the user space interface exposed by it, so
|
|||
|
|
``intel_pstate`` maps its internal representation of P-states to frequencies too
|
|||
|
|
(fortunately, that mapping is unambiguous). At the same time, it would not be
|
|||
|
|
practical for ``intel_pstate`` to supply the ``CPUFreq`` core with a table of
|
|||
|
|
available frequencies due to the possible size of it, so the driver does not do
|
|||
|
|
that. Some functionality of the core is limited by that.
|
|||
|
|
|
|||
|
|
Since the hardware P-state selection interface used by ``intel_pstate`` is
|
|||
|
|
available at the logical CPU level, the driver always works with individual
|
|||
|
|
CPUs. Consequently, if ``intel_pstate`` is in use, every ``CPUFreq`` policy
|
|||
|
|
object corresponds to one logical CPU and ``CPUFreq`` policies are effectively
|
|||
|
|
equivalent to CPUs. In particular, this means that they become "inactive" every
|
|||
|
|
time the corresponding CPU is taken offline and need to be re-initialized when
|
|||
|
|
it goes back online.
|
|||
|
|
|
|||
|
|
``intel_pstate`` is not modular, so it cannot be unloaded, which means that the
|
|||
|
|
only way to pass early-configuration-time parameters to it is via the kernel
|
|||
|
|
command line. However, its configuration can be adjusted via ``sysfs`` to a
|
|||
|
|
great extent. In some configurations it even is possible to unregister it via
|
|||
|
|
``sysfs`` which allows another ``CPUFreq`` scaling driver to be loaded and
|
|||
|
|
registered (see `below <status_attr_>`_).
|
|||
|
|
|
|||
|
|
|
|||
|
|
Operation Modes
|
|||
|
|
===============
|
|||
|
|
|
|||
|
|
``intel_pstate`` can operate in three different modes: in the active mode with
|
|||
|
|
or without hardware-managed P-states support and in the passive mode. Which of
|
|||
|
|
them will be in effect depends on what kernel command line options are used and
|
|||
|
|
on the capabilities of the processor.
|
|||
|
|
|
|||
|
|
Active Mode
|
|||
|
|
-----------
|
|||
|
|
|
|||
|
|
This is the default operation mode of ``intel_pstate``. If it works in this
|
|||
|
|
mode, the ``scaling_driver`` policy attribute in ``sysfs`` for all ``CPUFreq``
|
|||
|
|
policies contains the string "intel_pstate".
|
|||
|
|
|
|||
|
|
In this mode the driver bypasses the scaling governors layer of ``CPUFreq`` and
|
|||
|
|
provides its own scaling algorithms for P-state selection. Those algorithms
|
|||
|
|
can be applied to ``CPUFreq`` policies in the same way as generic scaling
|
|||
|
|
governors (that is, through the ``scaling_governor`` policy attribute in
|
|||
|
|
``sysfs``). [Note that different P-state selection algorithms may be chosen for
|
|||
|
|
different policies, but that is not recommended.]
|
|||
|
|
|
|||
|
|
They are not generic scaling governors, but their names are the same as the
|
|||
|
|
names of some of those governors. Moreover, confusingly enough, they generally
|
|||
|
|
do not work in the same way as the generic governors they share the names with.
|
|||
|
|
For example, the ``powersave`` P-state selection algorithm provided by
|
|||
|
|
``intel_pstate`` is not a counterpart of the generic ``powersave`` governor
|
|||
|
|
(roughly, it corresponds to the ``schedutil`` and ``ondemand`` governors).
|
|||
|
|
|
|||
|
|
There are two P-state selection algorithms provided by ``intel_pstate`` in the
|
|||
|
|
active mode: ``powersave`` and ``performance``. The way they both operate
|
|||
|
|
depends on whether or not the hardware-managed P-states (HWP) feature has been
|
|||
|
|
enabled in the processor and possibly on the processor model.
|
|||
|
|
|
|||
|
|
Which of the P-state selection algorithms is used by default depends on the
|
|||
|
|
:c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option.
|
|||
|
|
Namely, if that option is set, the ``performance`` algorithm will be used by
|
|||
|
|
default, and the other one will be used by default if it is not set.
|
|||
|
|
|
|||
|
|
Active Mode With HWP
|
|||
|
|
~~~~~~~~~~~~~~~~~~~~
|
|||
|
|
|
|||
|
|
If the processor supports the HWP feature, it will be enabled during the
|
|||
|
|
processor initialization and cannot be disabled after that. It is possible
|
|||
|
|
to avoid enabling it by passing the ``intel_pstate=no_hwp`` argument to the
|
|||
|
|
kernel in the command line.
|
|||
|
|
|
|||
|
|
If the HWP feature has been enabled, ``intel_pstate`` relies on the processor to
|
|||
|
|
select P-states by itself, but still it can give hints to the processor's
|
|||
|
|
internal P-state selection logic. What those hints are depends on which P-state
|
|||
|
|
selection algorithm has been applied to the given policy (or to the CPU it
|
|||
|
|
corresponds to).
|
|||
|
|
|
|||
|
|
Even though the P-state selection is carried out by the processor automatically,
|
|||
|
|
``intel_pstate`` registers utilization update callbacks with the CPU scheduler
|
|||
|
|
in this mode. However, they are not used for running a P-state selection
|
|||
|
|
algorithm, but for periodic updates of the current CPU frequency information to
|
|||
|
|
be made available from the ``scaling_cur_freq`` policy attribute in ``sysfs``.
|
|||
|
|
|
|||
|
|
HWP + ``performance``
|
|||
|
|
.....................
|
|||
|
|
|
|||
|
|
In this configuration ``intel_pstate`` will write 0 to the processor's
|
|||
|
|
Energy-Performance Preference (EPP) knob (if supported) or its
|
|||
|
|
Energy-Performance Bias (EPB) knob (otherwise), which means that the processor's
|
|||
|
|
internal P-state selection logic is expected to focus entirely on performance.
|
|||
|
|
|
|||
|
|
This will override the EPP/EPB setting coming from the ``sysfs`` interface
|
|||
|
|
(see `Energy vs Performance Hints`_ below).
|
|||
|
|
|
|||
|
|
Also, in this configuration the range of P-states available to the processor's
|
|||
|
|
internal P-state selection logic is always restricted to the upper boundary
|
|||
|
|
(that is, the maximum P-state that the driver is allowed to use).
|
|||
|
|
|
|||
|
|
HWP + ``powersave``
|
|||
|
|
...................
|
|||
|
|
|
|||
|
|
In this configuration ``intel_pstate`` will set the processor's
|
|||
|
|
Energy-Performance Preference (EPP) knob (if supported) or its
|
|||
|
|
Energy-Performance Bias (EPB) knob (otherwise) to whatever value it was
|
|||
|
|
previously set to via ``sysfs`` (or whatever default value it was
|
|||
|
|
set to by the platform firmware). This usually causes the processor's
|
|||
|
|
internal P-state selection logic to be less performance-focused.
|
|||
|
|
|
|||
|
|
Active Mode Without HWP
|
|||
|
|
~~~~~~~~~~~~~~~~~~~~~~~
|
|||
|
|
|
|||
|
|
This is the default operation mode for processors that do not support the HWP
|
|||
|
|
feature. It also is used by default with the ``intel_pstate=no_hwp`` argument
|
|||
|
|
in the kernel command line. However, in this mode ``intel_pstate`` may refuse
|
|||
|
|
to work with the given processor if it does not recognize it. [Note that
|
|||
|
|
``intel_pstate`` will never refuse to work with any processor with the HWP
|
|||
|
|
feature enabled.]
|
|||
|
|
|
|||
|
|
In this mode ``intel_pstate`` registers utilization update callbacks with the
|
|||
|
|
CPU scheduler in order to run a P-state selection algorithm, either
|
|||
|
|
``powersave`` or ``performance``, depending on the ``scaling_governor`` policy
|
|||
|
|
setting in ``sysfs``. The current CPU frequency information to be made
|
|||
|
|
available from the ``scaling_cur_freq`` policy attribute in ``sysfs`` is
|
|||
|
|
periodically updated by those utilization update callbacks too.
|
|||
|
|
|
|||
|
|
``performance``
|
|||
|
|
...............
|
|||
|
|
|
|||
|
|
Without HWP, this P-state selection algorithm is always the same regardless of
|
|||
|
|
the processor model and platform configuration.
|
|||
|
|
|
|||
|
|
It selects the maximum P-state it is allowed to use, subject to limits set via
|
|||
|
|
``sysfs``, every time the driver configuration for the given CPU is updated
|
|||
|
|
(e.g. via ``sysfs``).
|
|||
|
|
|
|||
|
|
This is the default P-state selection algorithm if the
|
|||
|
|
:c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option
|
|||
|
|
is set.
|
|||
|
|
|
|||
|
|
``powersave``
|
|||
|
|
.............
|
|||
|
|
|
|||
|
|
Without HWP, this P-state selection algorithm is similar to the algorithm
|
|||
|
|
implemented by the generic ``schedutil`` scaling governor except that the
|
|||
|
|
utilization metric used by it is based on numbers coming from feedback
|
|||
|
|
registers of the CPU. It generally selects P-states proportional to the
|
|||
|
|
current CPU utilization.
|
|||
|
|
|
|||
|
|
This algorithm is run by the driver's utilization update callback for the
|
|||
|
|
given CPU when it is invoked by the CPU scheduler, but not more often than
|
|||
|
|
every 10 ms. Like in the ``performance`` case, the hardware configuration
|
|||
|
|
is not touched if the new P-state turns out to be the same as the current
|
|||
|
|
one.
|
|||
|
|
|
|||
|
|
This is the default P-state selection algorithm if the
|
|||
|
|
:c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option
|
|||
|
|
is not set.
|
|||
|
|
|
|||
|
|
Passive Mode
|
|||
|
|
------------
|
|||
|
|
|
|||
|
|
This mode is used if the ``intel_pstate=passive`` argument is passed to the
|
|||
|
|
kernel in the command line (it implies the ``intel_pstate=no_hwp`` setting too).
|
|||
|
|
Like in the active mode without HWP support, in this mode ``intel_pstate`` may
|
|||
|
|
refuse to work with the given processor if it does not recognize it.
|
|||
|
|
|
|||
|
|
If the driver works in this mode, the ``scaling_driver`` policy attribute in
|
|||
|
|
``sysfs`` for all ``CPUFreq`` policies contains the string "intel_cpufreq".
|
|||
|
|
Then, the driver behaves like a regular ``CPUFreq`` scaling driver. That is,
|
|||
|
|
it is invoked by generic scaling governors when necessary to talk to the
|
|||
|
|
hardware in order to change the P-state of a CPU (in particular, the
|
|||
|
|
``schedutil`` governor can invoke it directly from scheduler context).
|
|||
|
|
|
|||
|
|
While in this mode, ``intel_pstate`` can be used with all of the (generic)
|
|||
|
|
scaling governors listed by the ``scaling_available_governors`` policy attribute
|
|||
|
|
in ``sysfs`` (and the P-state selection algorithms described above are not
|
|||
|
|
used). Then, it is responsible for the configuration of policy objects
|
|||
|
|
corresponding to CPUs and provides the ``CPUFreq`` core (and the scaling
|
|||
|
|
governors attached to the policy objects) with accurate information on the
|
|||
|
|
maximum and minimum operating frequencies supported by the hardware (including
|
|||
|
|
the so-called "turbo" frequency ranges). In other words, in the passive mode
|
|||
|
|
the entire range of available P-states is exposed by ``intel_pstate`` to the
|
|||
|
|
``CPUFreq`` core. However, in this mode the driver does not register
|
|||
|
|
utilization update callbacks with the CPU scheduler and the ``scaling_cur_freq``
|
|||
|
|
information comes from the ``CPUFreq`` core (and is the last frequency selected
|
|||
|
|
by the current scaling governor for the given policy).
|
|||
|
|
|
|||
|
|
|
|||
|
|
.. _turbo:
|
|||
|
|
|
|||
|
|
Turbo P-states Support
|
|||
|
|
======================
|
|||
|
|
|
|||
|
|
In the majority of cases, the entire range of P-states available to
|
|||
|
|
``intel_pstate`` can be divided into two sub-ranges that correspond to
|
|||
|
|
different types of processor behavior, above and below a boundary that
|
|||
|
|
will be referred to as the "turbo threshold" in what follows.
|
|||
|
|
|
|||
|
|
The P-states above the turbo threshold are referred to as "turbo P-states" and
|
|||
|
|
the whole sub-range of P-states they belong to is referred to as the "turbo
|
|||
|
|
range". These names are related to the Turbo Boost technology allowing a
|
|||
|
|
multicore processor to opportunistically increase the P-state of one or more
|
|||
|
|
cores if there is enough power to do that and if that is not going to cause the
|
|||
|
|
thermal envelope of the processor package to be exceeded.
|
|||
|
|
|
|||
|
|
Specifically, if software sets the P-state of a CPU core within the turbo range
|
|||
|
|
(that is, above the turbo threshold), the processor is permitted to take over
|
|||
|
|
performance scaling control for that core and put it into turbo P-states of its
|
|||
|
|
choice going forward. However, that permission is interpreted differently by
|
|||
|
|
different processor generations. Namely, the Sandy Bridge generation of
|
|||
|
|
processors will never use any P-states above the last one set by software for
|
|||
|
|
the given core, even if it is within the turbo range, whereas all of the later
|
|||
|
|
processor generations will take it as a license to use any P-states from the
|
|||
|
|
turbo range, even above the one set by software. In other words, on those
|
|||
|
|
processors setting any P-state from the turbo range will enable the processor
|
|||
|
|
to put the given core into all turbo P-states up to and including the maximum
|
|||
|
|
supported one as it sees fit.
|
|||
|
|
|
|||
|
|
One important property of turbo P-states is that they are not sustainable. More
|
|||
|
|
precisely, there is no guarantee that any CPUs will be able to stay in any of
|
|||
|
|
those states indefinitely, because the power distribution within the processor
|
|||
|
|
package may change over time or the thermal envelope it was designed for might
|
|||
|
|
be exceeded if a turbo P-state was used for too long.
|
|||
|
|
|
|||
|
|
In turn, the P-states below the turbo threshold generally are sustainable. In
|
|||
|
|
fact, if one of them is set by software, the processor is not expected to change
|
|||
|
|
it to a lower one unless in a thermal stress or a power limit violation
|
|||
|
|
situation (a higher P-state may still be used if it is set for another CPU in
|
|||
|
|
the same package at the same time, for example).
|
|||
|
|
|
|||
|
|
Some processors allow multiple cores to be in turbo P-states at the same time,
|
|||
|
|
but the maximum P-state that can be set for them generally depends on the number
|
|||
|
|
of cores running concurrently. The maximum turbo P-state that can be set for 3
|
|||
|
|
cores at the same time usually is lower than the analogous maximum P-state for
|
|||
|
|
2 cores, which in turn usually is lower than the maximum turbo P-state that can
|
|||
|
|
be set for 1 core. The one-core maximum turbo P-state is thus the maximum
|
|||
|
|
supported one overall.
|
|||
|
|
|
|||
|
|
The maximum supported turbo P-state, the turbo threshold (the maximum supported
|
|||
|
|
non-turbo P-state) and the minimum supported P-state are specific to the
|
|||
|
|
processor model and can be determined by reading the processor's model-specific
|
|||
|
|
registers (MSRs). Moreover, some processors support the Configurable TDP
|
|||
|
|
(Thermal Design Power) feature and, when that feature is enabled, the turbo
|
|||
|
|
threshold effectively becomes a configurable value that can be set by the
|
|||
|
|
platform firmware.
|
|||
|
|
|
|||
|
|
Unlike ``_PSS`` objects in the ACPI tables, ``intel_pstate`` always exposes
|
|||
|
|
the entire range of available P-states, including the whole turbo range, to the
|
|||
|
|
``CPUFreq`` core and (in the passive mode) to generic scaling governors. This
|
|||
|
|
generally causes turbo P-states to be set more often when ``intel_pstate`` is
|
|||
|
|
used relative to ACPI-based CPU performance scaling (see `below <acpi-cpufreq_>`_
|
|||
|
|
for more information).
|
|||
|
|
|
|||
|
|
Moreover, since ``intel_pstate`` always knows what the real turbo threshold is
|
|||
|
|
(even if the Configurable TDP feature is enabled in the processor), its
|
|||
|
|
``no_turbo`` attribute in ``sysfs`` (described `below <no_turbo_attr_>`_) should
|
|||
|
|
work as expected in all cases (that is, if set to disable turbo P-states, it
|
|||
|
|
always should prevent ``intel_pstate`` from using them).
|
|||
|
|
|
|||
|
|
|
|||
|
|
Processor Support
|
|||
|
|
=================
|
|||
|
|
|
|||
|
|
To handle a given processor ``intel_pstate`` requires a number of different
|
|||
|
|
pieces of information on it to be known, including:
|
|||
|
|
|
|||
|
|
* The minimum supported P-state.
|
|||
|
|
|
|||
|
|
* The maximum supported `non-turbo P-state <turbo_>`_.
|
|||
|
|
|
|||
|
|
* Whether or not turbo P-states are supported at all.
|
|||
|
|
|
|||
|
|
* The maximum supported `one-core turbo P-state <turbo_>`_ (if turbo P-states
|
|||
|
|
are supported).
|
|||
|
|
|
|||
|
|
* The scaling formula to translate the driver's internal representation
|
|||
|
|
of P-states into frequencies and the other way around.
|
|||
|
|
|
|||
|
|
Generally, ways to obtain that information are specific to the processor model
|
|||
|
|
or family. Although it often is possible to obtain all of it from the processor
|
|||
|
|
itself (using model-specific registers), there are cases in which hardware
|
|||
|
|
manuals need to be consulted to get to it too.
|
|||
|
|
|
|||
|
|
For this reason, there is a list of supported processors in ``intel_pstate`` and
|
|||
|
|
the driver initialization will fail if the detected processor is not in that
|
|||
|
|
list, unless it supports the `HWP feature <Active Mode_>`_. [The interface to
|
|||
|
|
obtain all of the information listed above is the same for all of the processors
|
|||
|
|
supporting the HWP feature, which is why they all are supported by
|
|||
|
|
``intel_pstate``.]
|
|||
|
|
|
|||
|
|
|
|||
|
|
User Space Interface in ``sysfs``
|
|||
|
|
=================================
|
|||
|
|
|
|||
|
|
Global Attributes
|
|||
|
|
-----------------
|
|||
|
|
|
|||
|
|
``intel_pstate`` exposes several global attributes (files) in ``sysfs`` to
|
|||
|
|
control its functionality at the system level. They are located in the
|
|||
|
|
``/sys/devices/system/cpu/intel_pstate/`` directory and affect all CPUs.
|
|||
|
|
|
|||
|
|
Some of them are not present if the ``intel_pstate=per_cpu_perf_limits``
|
|||
|
|
argument is passed to the kernel in the command line.
|
|||
|
|
|
|||
|
|
``max_perf_pct``
|
|||
|
|
Maximum P-state the driver is allowed to set in percent of the
|
|||
|
|
maximum supported performance level (the highest supported `turbo
|
|||
|
|
P-state <turbo_>`_).
|
|||
|
|
|
|||
|
|
This attribute will not be exposed if the
|
|||
|
|
``intel_pstate=per_cpu_perf_limits`` argument is present in the kernel
|
|||
|
|
command line.
|
|||
|
|
|
|||
|
|
``min_perf_pct``
|
|||
|
|
Minimum P-state the driver is allowed to set in percent of the
|
|||
|
|
maximum supported performance level (the highest supported `turbo
|
|||
|
|
P-state <turbo_>`_).
|
|||
|
|
|
|||
|
|
This attribute will not be exposed if the
|
|||
|
|
``intel_pstate=per_cpu_perf_limits`` argument is present in the kernel
|
|||
|
|
command line.
|
|||
|
|
|
|||
|
|
``num_pstates``
|
|||
|
|
Number of P-states supported by the processor (between 0 and 255
|
|||
|
|
inclusive) including both turbo and non-turbo P-states (see
|
|||
|
|
`Turbo P-states Support`_).
|
|||
|
|
|
|||
|
|
The value of this attribute is not affected by the ``no_turbo``
|
|||
|
|
setting described `below <no_turbo_attr_>`_.
|
|||
|
|
|
|||
|
|
This attribute is read-only.
|
|||
|
|
|
|||
|
|
``turbo_pct``
|
|||
|
|
Ratio of the `turbo range <turbo_>`_ size to the size of the entire
|
|||
|
|
range of supported P-states, in percent.
|
|||
|
|
|
|||
|
|
This attribute is read-only.
|
|||
|
|
|
|||
|
|
.. _no_turbo_attr:
|
|||
|
|
|
|||
|
|
``no_turbo``
|
|||
|
|
If set (equal to 1), the driver is not allowed to set any turbo P-states
|
|||
|
|
(see `Turbo P-states Support`_). If unset (equalt to 0, which is the
|
|||
|
|
default), turbo P-states can be set by the driver.
|
|||
|
|
[Note that ``intel_pstate`` does not support the general ``boost``
|
|||
|
|
attribute (supported by some other scaling drivers) which is replaced
|
|||
|
|
by this one.]
|
|||
|
|
|
|||
|
|
This attrubute does not affect the maximum supported frequency value
|
|||
|
|
supplied to the ``CPUFreq`` core and exposed via the policy interface,
|
|||
|
|
but it affects the maximum possible value of per-policy P-state limits
|
|||
|
|
(see `Interpretation of Policy Attributes`_ below for details).
|
|||
|
|
|
|||
|
|
``hwp_dynamic_boost``
|
|||
|
|
This attribute is only present if ``intel_pstate`` works in the
|
|||
|
|
`active mode with the HWP feature enabled <Active Mode With HWP_>`_ in
|
|||
|
|
the processor. If set (equal to 1), it causes the minimum P-state limit
|
|||
|
|
to be increased dynamically for a short time whenever a task previously
|
|||
|
|
waiting on I/O is selected to run on a given logical CPU (the purpose
|
|||
|
|
of this mechanism is to improve performance).
|
|||
|
|
|
|||
|
|
This setting has no effect on logical CPUs whose minimum P-state limit
|
|||
|
|
is directly set to the highest non-turbo P-state or above it.
|
|||
|
|
|
|||
|
|
.. _status_attr:
|
|||
|
|
|
|||
|
|
``status``
|
|||
|
|
Operation mode of the driver: "active", "passive" or "off".
|
|||
|
|
|
|||
|
|
"active"
|
|||
|
|
The driver is functional and in the `active mode
|
|||
|
|
<Active Mode_>`_.
|
|||
|
|
|
|||
|
|
"passive"
|
|||
|
|
The driver is functional and in the `passive mode
|
|||
|
|
<Passive Mode_>`_.
|
|||
|
|
|
|||
|
|
"off"
|
|||
|
|
The driver is not functional (it is not registered as a scaling
|
|||
|
|
driver with the ``CPUFreq`` core).
|
|||
|
|
|
|||
|
|
This attribute can be written to in order to change the driver's
|
|||
|
|
operation mode or to unregister it. The string written to it must be
|
|||
|
|
one of the possible values of it and, if successful, the write will
|
|||
|
|
cause the driver to switch over to the operation mode represented by
|
|||
|
|
that string - or to be unregistered in the "off" case. [Actually,
|
|||
|
|
switching over from the active mode to the passive mode or the other
|
|||
|
|
way around causes the driver to be unregistered and registered again
|
|||
|
|
with a different set of callbacks, so all of its settings (the global
|
|||
|
|
as well as the per-policy ones) are then reset to their default
|
|||
|
|
values, possibly depending on the target operation mode.]
|
|||
|
|
|
|||
|
|
That only is supported in some configurations, though (for example, if
|
|||
|
|
the `HWP feature is enabled in the processor <Active Mode With HWP_>`_,
|
|||
|
|
the operation mode of the driver cannot be changed), and if it is not
|
|||
|
|
supported in the current configuration, writes to this attribute will
|
|||
|
|
fail with an appropriate error.
|
|||
|
|
|
|||
|
|
Interpretation of Policy Attributes
|
|||
|
|
-----------------------------------
|
|||
|
|
|
|||
|
|
The interpretation of some ``CPUFreq`` policy attributes described in
|
|||
|
|
:doc:`cpufreq` is special with ``intel_pstate`` as the current scaling driver
|
|||
|
|
and it generally depends on the driver's `operation mode <Operation Modes_>`_.
|
|||
|
|
|
|||
|
|
First of all, the values of the ``cpuinfo_max_freq``, ``cpuinfo_min_freq`` and
|
|||
|
|
``scaling_cur_freq`` attributes are produced by applying a processor-specific
|
|||
|
|
multiplier to the internal P-state representation used by ``intel_pstate``.
|
|||
|
|
Also, the values of the ``scaling_max_freq`` and ``scaling_min_freq``
|
|||
|
|
attributes are capped by the frequency corresponding to the maximum P-state that
|
|||
|
|
the driver is allowed to set.
|
|||
|
|
|
|||
|
|
If the ``no_turbo`` `global attribute <no_turbo_attr_>`_ is set, the driver is
|
|||
|
|
not allowed to use turbo P-states, so the maximum value of ``scaling_max_freq``
|
|||
|
|
and ``scaling_min_freq`` is limited to the maximum non-turbo P-state frequency.
|
|||
|
|
Accordingly, setting ``no_turbo`` causes ``scaling_max_freq`` and
|
|||
|
|
``scaling_min_freq`` to go down to that value if they were above it before.
|
|||
|
|
However, the old values of ``scaling_max_freq`` and ``scaling_min_freq`` will be
|
|||
|
|
restored after unsetting ``no_turbo``, unless these attributes have been written
|
|||
|
|
to after ``no_turbo`` was set.
|
|||
|
|
|
|||
|
|
If ``no_turbo`` is not set, the maximum possible value of ``scaling_max_freq``
|
|||
|
|
and ``scaling_min_freq`` corresponds to the maximum supported turbo P-state,
|
|||
|
|
which also is the value of ``cpuinfo_max_freq`` in either case.
|
|||
|
|
|
|||
|
|
Next, the following policy attributes have special meaning if
|
|||
|
|
``intel_pstate`` works in the `active mode <Active Mode_>`_:
|
|||
|
|
|
|||
|
|
``scaling_available_governors``
|
|||
|
|
List of P-state selection algorithms provided by ``intel_pstate``.
|
|||
|
|
|
|||
|
|
``scaling_governor``
|
|||
|
|
P-state selection algorithm provided by ``intel_pstate`` currently in
|
|||
|
|
use with the given policy.
|
|||
|
|
|
|||
|
|
``scaling_cur_freq``
|
|||
|
|
Frequency of the average P-state of the CPU represented by the given
|
|||
|
|
policy for the time interval between the last two invocations of the
|
|||
|
|
driver's utilization update callback by the CPU scheduler for that CPU.
|
|||
|
|
|
|||
|
|
One more policy attribute is present if the `HWP feature is enabled in the
|
|||
|
|
processor <Active Mode With HWP_>`_:
|
|||
|
|
|
|||
|
|
``base_frequency``
|
|||
|
|
Shows the base frequency of the CPU. Any frequency above this will be
|
|||
|
|
in the turbo frequency range.
|
|||
|
|
|
|||
|
|
The meaning of these attributes in the `passive mode <Passive Mode_>`_ is the
|
|||
|
|
same as for other scaling drivers.
|
|||
|
|
|
|||
|
|
Additionally, the value of the ``scaling_driver`` attribute for ``intel_pstate``
|
|||
|
|
depends on the operation mode of the driver. Namely, it is either
|
|||
|
|
"intel_pstate" (in the `active mode <Active Mode_>`_) or "intel_cpufreq" (in the
|
|||
|
|
`passive mode <Passive Mode_>`_).
|
|||
|
|
|
|||
|
|
Coordination of P-State Limits
|
|||
|
|
------------------------------
|
|||
|
|
|
|||
|
|
``intel_pstate`` allows P-state limits to be set in two ways: with the help of
|
|||
|
|
the ``max_perf_pct`` and ``min_perf_pct`` `global attributes
|
|||
|
|
<Global Attributes_>`_ or via the ``scaling_max_freq`` and ``scaling_min_freq``
|
|||
|
|
``CPUFreq`` policy attributes. The coordination between those limits is based
|
|||
|
|
on the following rules, regardless of the current operation mode of the driver:
|
|||
|
|
|
|||
|
|
1. All CPUs are affected by the global limits (that is, none of them can be
|
|||
|
|
requested to run faster than the global maximum and none of them can be
|
|||
|
|
requested to run slower than the global minimum).
|
|||
|
|
|
|||
|
|
2. Each individual CPU is affected by its own per-policy limits (that is, it
|
|||
|
|
cannot be requested to run faster than its own per-policy maximum and it
|
|||
|
|
cannot be requested to run slower than its own per-policy minimum). The
|
|||
|
|
effective performance depends on whether the platform supports per core
|
|||
|
|
P-states, hyper-threading is enabled and on current performance requests
|
|||
|
|
from other CPUs. When platform doesn't support per core P-states, the
|
|||
|
|
effective performance can be more than the policy limits set on a CPU, if
|
|||
|
|
other CPUs are requesting higher performance at that moment. Even with per
|
|||
|
|
core P-states support, when hyper-threading is enabled, if the sibling CPU
|
|||
|
|
is requesting higher performance, the other siblings will get higher
|
|||
|
|
performance than their policy limits.
|
|||
|
|
|
|||
|
|
3. The global and per-policy limits can be set independently.
|
|||
|
|
|
|||
|
|
If the `HWP feature is enabled in the processor <Active Mode With HWP_>`_, the
|
|||
|
|
resulting effective values are written into its registers whenever the limits
|
|||
|
|
change in order to request its internal P-state selection logic to always set
|
|||
|
|
P-states within these limits. Otherwise, the limits are taken into account by
|
|||
|
|
scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver
|
|||
|
|
every time before setting a new P-state for a CPU.
|
|||
|
|
|
|||
|
|
Additionally, if the ``intel_pstate=per_cpu_perf_limits`` command line argument
|
|||
|
|
is passed to the kernel, ``max_perf_pct`` and ``min_perf_pct`` are not exposed
|
|||
|
|
at all and the only way to set the limits is by using the policy attributes.
|
|||
|
|
|
|||
|
|
|
|||
|
|
Energy vs Performance Hints
|
|||
|
|
---------------------------
|
|||
|
|
|
|||
|
|
If ``intel_pstate`` works in the `active mode with the HWP feature enabled
|
|||
|
|
<Active Mode With HWP_>`_ in the processor, additional attributes are present
|
|||
|
|
in every ``CPUFreq`` policy directory in ``sysfs``. They are intended to allow
|
|||
|
|
user space to help ``intel_pstate`` to adjust the processor's internal P-state
|
|||
|
|
selection logic by focusing it on performance or on energy-efficiency, or
|
|||
|
|
somewhere between the two extremes:
|
|||
|
|
|
|||
|
|
``energy_performance_preference``
|
|||
|
|
Current value of the energy vs performance hint for the given policy
|
|||
|
|
(or the CPU represented by it).
|
|||
|
|
|
|||
|
|
The hint can be changed by writing to this attribute.
|
|||
|
|
|
|||
|
|
``energy_performance_available_preferences``
|
|||
|
|
List of strings that can be written to the
|
|||
|
|
``energy_performance_preference`` attribute.
|
|||
|
|
|
|||
|
|
They represent different energy vs performance hints and should be
|
|||
|
|
self-explanatory, except that ``default`` represents whatever hint
|
|||
|
|
value was set by the platform firmware.
|
|||
|
|
|
|||
|
|
Strings written to the ``energy_performance_preference`` attribute are
|
|||
|
|
internally translated to integer values written to the processor's
|
|||
|
|
Energy-Performance Preference (EPP) knob (if supported) or its
|
|||
|
|
Energy-Performance Bias (EPB) knob.
|
|||
|
|
|
|||
|
|
[Note that tasks may by migrated from one CPU to another by the scheduler's
|
|||
|
|
load-balancing algorithm and if different energy vs performance hints are
|
|||
|
|
set for those CPUs, that may lead to undesirable outcomes. To avoid such
|
|||
|
|
issues it is better to set the same energy vs performance hint for all CPUs
|
|||
|
|
or to pin every task potentially sensitive to them to a specific CPU.]
|
|||
|
|
|
|||
|
|
.. _acpi-cpufreq:
|
|||
|
|
|
|||
|
|
``intel_pstate`` vs ``acpi-cpufreq``
|
|||
|
|
====================================
|
|||
|
|
|
|||
|
|
On the majority of systems supported by ``intel_pstate``, the ACPI tables
|
|||
|
|
provided by the platform firmware contain ``_PSS`` objects returning information
|
|||
|
|
that can be used for CPU performance scaling (refer to the ACPI specification
|
|||
|
|
[3]_ for details on the ``_PSS`` objects and the format of the information
|
|||
|
|
returned by them).
|
|||
|
|
|
|||
|
|
The information returned by the ACPI ``_PSS`` objects is used by the
|
|||
|
|
``acpi-cpufreq`` scaling driver. On systems supported by ``intel_pstate``
|
|||
|
|
the ``acpi-cpufreq`` driver uses the same hardware CPU performance scaling
|
|||
|
|
interface, but the set of P-states it can use is limited by the ``_PSS``
|
|||
|
|
output.
|
|||
|
|
|
|||
|
|
On those systems each ``_PSS`` object returns a list of P-states supported by
|
|||
|
|
the corresponding CPU which basically is a subset of the P-states range that can
|
|||
|
|
be used by ``intel_pstate`` on the same system, with one exception: the whole
|
|||
|
|
`turbo range <turbo_>`_ is represented by one item in it (the topmost one). By
|
|||
|
|
convention, the frequency returned by ``_PSS`` for that item is greater by 1 MHz
|
|||
|
|
than the frequency of the highest non-turbo P-state listed by it, but the
|
|||
|
|
corresponding P-state representation (following the hardware specification)
|
|||
|
|
returned for it matches the maximum supported turbo P-state (or is the
|
|||
|
|
special value 255 meaning essentially "go as high as you can get").
|
|||
|
|
|
|||
|
|
The list of P-states returned by ``_PSS`` is reflected by the table of
|
|||
|
|
available frequencies supplied by ``acpi-cpufreq`` to the ``CPUFreq`` core and
|
|||
|
|
scaling governors and the minimum and maximum supported frequencies reported by
|
|||
|
|
it come from that list as well. In particular, given the special representation
|
|||
|
|
of the turbo range described above, this means that the maximum supported
|
|||
|
|
frequency reported by ``acpi-cpufreq`` is higher by 1 MHz than the frequency
|
|||
|
|
of the highest supported non-turbo P-state listed by ``_PSS`` which, of course,
|
|||
|
|
affects decisions made by the scaling governors, except for ``powersave`` and
|
|||
|
|
``performance``.
|
|||
|
|
|
|||
|
|
For example, if a given governor attempts to select a frequency proportional to
|
|||
|
|
estimated CPU load and maps the load of 100% to the maximum supported frequency
|
|||
|
|
(possibly multiplied by a constant), then it will tend to choose P-states below
|
|||
|
|
the turbo threshold if ``acpi-cpufreq`` is used as the scaling driver, because
|
|||
|
|
in that case the turbo range corresponds to a small fraction of the frequency
|
|||
|
|
band it can use (1 MHz vs 1 GHz or more). In consequence, it will only go to
|
|||
|
|
the turbo range for the highest loads and the other loads above 50% that might
|
|||
|
|
benefit from running at turbo frequencies will be given non-turbo P-states
|
|||
|
|
instead.
|
|||
|
|
|
|||
|
|
One more issue related to that may appear on systems supporting the
|
|||
|
|
`Configurable TDP feature <turbo_>`_ allowing the platform firmware to set the
|
|||
|
|
turbo threshold. Namely, if that is not coordinated with the lists of P-states
|
|||
|
|
returned by ``_PSS`` properly, there may be more than one item corresponding to
|
|||
|
|
a turbo P-state in those lists and there may be a problem with avoiding the
|
|||
|
|
turbo range (if desirable or necessary). Usually, to avoid using turbo
|
|||
|
|
P-states overall, ``acpi-cpufreq`` simply avoids using the topmost state listed
|
|||
|
|
by ``_PSS``, but that is not sufficient when there are other turbo P-states in
|
|||
|
|
the list returned by it.
|
|||
|
|
|
|||
|
|
Apart from the above, ``acpi-cpufreq`` works like ``intel_pstate`` in the
|
|||
|
|
`passive mode <Passive Mode_>`_, except that the number of P-states it can set
|
|||
|
|
is limited to the ones listed by the ACPI ``_PSS`` objects.
|
|||
|
|
|
|||
|
|
|
|||
|
|
Kernel Command Line Options for ``intel_pstate``
|
|||
|
|
================================================
|
|||
|
|
|
|||
|
|
Several kernel command line options can be used to pass early-configuration-time
|
|||
|
|
parameters to ``intel_pstate`` in order to enforce specific behavior of it. All
|
|||
|
|
of them have to be prepended with the ``intel_pstate=`` prefix.
|
|||
|
|
|
|||
|
|
``disable``
|
|||
|
|
Do not register ``intel_pstate`` as the scaling driver even if the
|
|||
|
|
processor is supported by it.
|
|||
|
|
|
|||
|
|
``passive``
|
|||
|
|
Register ``intel_pstate`` in the `passive mode <Passive Mode_>`_ to
|
|||
|
|
start with.
|
|||
|
|
|
|||
|
|
This option implies the ``no_hwp`` one described below.
|
|||
|
|
|
|||
|
|
``force``
|
|||
|
|
Register ``intel_pstate`` as the scaling driver instead of
|
|||
|
|
``acpi-cpufreq`` even if the latter is preferred on the given system.
|
|||
|
|
|
|||
|
|
This may prevent some platform features (such as thermal controls and
|
|||
|
|
power capping) that rely on the availability of ACPI P-states
|
|||
|
|
information from functioning as expected, so it should be used with
|
|||
|
|
caution.
|
|||
|
|
|
|||
|
|
This option does not work with processors that are not supported by
|
|||
|
|
``intel_pstate`` and on platforms where the ``pcc-cpufreq`` scaling
|
|||
|
|
driver is used instead of ``acpi-cpufreq``.
|
|||
|
|
|
|||
|
|
``no_hwp``
|
|||
|
|
Do not enable the `hardware-managed P-states (HWP) feature
|
|||
|
|
<Active Mode With HWP_>`_ even if it is supported by the processor.
|
|||
|
|
|
|||
|
|
``hwp_only``
|
|||
|
|
Register ``intel_pstate`` as the scaling driver only if the
|
|||
|
|
`hardware-managed P-states (HWP) feature <Active Mode With HWP_>`_ is
|
|||
|
|
supported by the processor.
|
|||
|
|
|
|||
|
|
``support_acpi_ppc``
|
|||
|
|
Take ACPI ``_PPC`` performance limits into account.
|
|||
|
|
|
|||
|
|
If the preferred power management profile in the FADT (Fixed ACPI
|
|||
|
|
Description Table) is set to "Enterprise Server" or "Performance
|
|||
|
|
Server", the ACPI ``_PPC`` limits are taken into account by default
|
|||
|
|
and this option has no effect.
|
|||
|
|
|
|||
|
|
``per_cpu_perf_limits``
|
|||
|
|
Use per-logical-CPU P-State limits (see `Coordination of P-state
|
|||
|
|
Limits`_ for details).
|
|||
|
|
|
|||
|
|
|
|||
|
|
Diagnostics and Tuning
|
|||
|
|
======================
|
|||
|
|
|
|||
|
|
Trace Events
|
|||
|
|
------------
|
|||
|
|
|
|||
|
|
There are two static trace events that can be used for ``intel_pstate``
|
|||
|
|
diagnostics. One of them is the ``cpu_frequency`` trace event generally used
|
|||
|
|
by ``CPUFreq``, and the other one is the ``pstate_sample`` trace event specific
|
|||
|
|
to ``intel_pstate``. Both of them are triggered by ``intel_pstate`` only if
|
|||
|
|
it works in the `active mode <Active Mode_>`_.
|
|||
|
|
|
|||
|
|
The following sequence of shell commands can be used to enable them and see
|
|||
|
|
their output (if the kernel is generally configured to support event tracing)::
|
|||
|
|
|
|||
|
|
# cd /sys/kernel/debug/tracing/
|
|||
|
|
# echo 1 > events/power/pstate_sample/enable
|
|||
|
|
# echo 1 > events/power/cpu_frequency/enable
|
|||
|
|
# cat trace
|
|||
|
|
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
|
|||
|
|
cat-5235 [002] ..s. 1177.681723: cpu_frequency: state=2900000 cpu_id=2
|
|||
|
|
|
|||
|
|
If ``intel_pstate`` works in the `passive mode <Passive Mode_>`_, the
|
|||
|
|
``cpu_frequency`` trace event will be triggered either by the ``schedutil``
|
|||
|
|
scaling governor (for the policies it is attached to), or by the ``CPUFreq``
|
|||
|
|
core (for the policies with other scaling governors).
|
|||
|
|
|
|||
|
|
``ftrace``
|
|||
|
|
----------
|
|||
|
|
|
|||
|
|
The ``ftrace`` interface can be used for low-level diagnostics of
|
|||
|
|
``intel_pstate``. For example, to check how often the function to set a
|
|||
|
|
P-state is called, the ``ftrace`` filter can be set to to
|
|||
|
|
:c:func:`intel_pstate_set_pstate`::
|
|||
|
|
|
|||
|
|
# cd /sys/kernel/debug/tracing/
|
|||
|
|
# cat available_filter_functions | grep -i pstate
|
|||
|
|
intel_pstate_set_pstate
|
|||
|
|
intel_pstate_cpu_init
|
|||
|
|
...
|
|||
|
|
# echo intel_pstate_set_pstate > set_ftrace_filter
|
|||
|
|
# echo function > current_tracer
|
|||
|
|
# cat trace | head -15
|
|||
|
|
# tracer: function
|
|||
|
|
#
|
|||
|
|
# entries-in-buffer/entries-written: 80/80 #P:4
|
|||
|
|
#
|
|||
|
|
# _-----=> irqs-off
|
|||
|
|
# / _----=> need-resched
|
|||
|
|
# | / _---=> hardirq/softirq
|
|||
|
|
# || / _--=> preempt-depth
|
|||
|
|
# ||| / delay
|
|||
|
|
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
|
|||
|
|
# | | | |||| | |
|
|||
|
|
Xorg-3129 [000] ..s. 2537.644844: intel_pstate_set_pstate <-intel_pstate_timer_func
|
|||
|
|
gnome-terminal--4510 [002] ..s. 2537.649844: intel_pstate_set_pstate <-intel_pstate_timer_func
|
|||
|
|
gnome-shell-3409 [001] ..s. 2537.650850: intel_pstate_set_pstate <-intel_pstate_timer_func
|
|||
|
|
<idle>-0 [000] ..s. 2537.654843: intel_pstate_set_pstate <-intel_pstate_timer_func
|
|||
|
|
|
|||
|
|
|
|||
|
|
References
|
|||
|
|
==========
|
|||
|
|
|
|||
|
|
.. [1] Kristen Accardi, *Balancing Power and Performance in the Linux Kernel*,
|
|||
|
|
http://events.linuxfoundation.org/sites/events/files/slides/LinuxConEurope_2015.pdf
|
|||
|
|
|
|||
|
|
.. [2] *Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3: System Programming Guide*,
|
|||
|
|
http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-system-programming-manual-325384.html
|
|||
|
|
|
|||
|
|
.. [3] *Advanced Configuration and Power Interface Specification*,
|
|||
|
|
https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
|