Skip to content

Commit ab271bc

Browse files
committed
Merge branch 'intel_pstate'
* intel_pstate: cpufreq: intel_pstate: Shorten a couple of long names cpufreq: intel_pstate: Simplify intel_pstate_adjust_pstate() cpufreq: intel_pstate: Improve IO performance with per-core P-states cpufreq: intel_pstate: Drop INTEL_PSTATE_HWP_SAMPLING_INTERVAL cpufreq: intel_pstate: Drop ->update_util from pstate_funcs cpufreq: intel_pstate: Do not use PID-based P-state selection
2 parents 08a1000 + 57ccaf3 commit ab271bc

File tree

2 files changed

+28
-353
lines changed

2 files changed

+28
-353
lines changed

Documentation/admin-guide/pm/intel_pstate.rst

Lines changed: 8 additions & 53 deletions
Original file line numberDiff line numberDiff line change
@@ -167,35 +167,17 @@ is set.
167167
``powersave``
168168
.............
169169

170-
Without HWP, this P-state selection algorithm generally depends on the
171-
processor model and/or the system profile setting in the ACPI tables and there
172-
are two variants of it.
173-
174-
One of them is used with processors from the Atom line and (regardless of the
175-
processor model) on platforms with the system profile in the ACPI tables set to
176-
"mobile" (laptops mostly), "tablet", "appliance PC", "desktop", or
177-
"workstation". It is also used with processors supporting the HWP feature if
178-
that feature has not been enabled (that is, with the ``intel_pstate=no_hwp``
179-
argument in the kernel command line). It is similar to the algorithm
170+
Without HWP, this P-state selection algorithm is similar to the algorithm
180171
implemented by the generic ``schedutil`` scaling governor except that the
181172
utilization metric used by it is based on numbers coming from feedback
182173
registers of the CPU. It generally selects P-states proportional to the
183-
current CPU utilization, so it is referred to as the "proportional" algorithm.
184-
185-
The second variant of the ``powersave`` P-state selection algorithm, used in all
186-
of the other cases (generally, on processors from the Core line, so it is
187-
referred to as the "Core" algorithm), is based on the values read from the APERF
188-
and MPERF feedback registers and the previously requested target P-state.
189-
It does not really take CPU utilization into account explicitly, but as a rule
190-
it causes the CPU P-state to ramp up very quickly in response to increased
191-
utilization which is generally desirable in server environments.
192-
193-
Regardless of the variant, this algorithm is run by the driver's utilization
194-
update callback for the given CPU when it is invoked by the CPU scheduler, but
195-
not more often than every 10 ms (that can be tweaked via ``debugfs`` in `this
196-
particular case <Tuning Interface in debugfs_>`_). Like in the ``performance``
197-
case, the hardware configuration is not touched if the new P-state turns out to
198-
be the same as the current one.
174+
current CPU utilization.
175+
176+
This algorithm is run by the driver's utilization update callback for the
177+
given CPU when it is invoked by the CPU scheduler, but not more often than
178+
every 10 ms. Like in the ``performance`` case, the hardware configuration
179+
is not touched if the new P-state turns out to be the same as the current
180+
one.
199181

200182
This is the default P-state selection algorithm if the
201183
:c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option
@@ -720,34 +702,7 @@ P-state is called, the ``ftrace`` filter can be set to to
720702
gnome-shell-3409 [001] ..s. 2537.650850: intel_pstate_set_pstate <-intel_pstate_timer_func
721703
<idle>-0 [000] ..s. 2537.654843: intel_pstate_set_pstate <-intel_pstate_timer_func
722704

723-
Tuning Interface in ``debugfs``
724-
-------------------------------
725-
726-
The ``powersave`` algorithm provided by ``intel_pstate`` for `the Core line of
727-
processors in the active mode <powersave_>`_ is based on a `PID controller`_
728-
whose parameters were chosen to address a number of different use cases at the
729-
same time. However, it still is possible to fine-tune it to a specific workload
730-
and the ``debugfs`` interface under ``/sys/kernel/debug/pstate_snb/`` is
731-
provided for this purpose. [Note that the ``pstate_snb`` directory will be
732-
present only if the specific P-state selection algorithm matching the interface
733-
in it actually is in use.]
734-
735-
The following files present in that directory can be used to modify the PID
736-
controller parameters at run time:
737-
738-
| ``deadband``
739-
| ``d_gain_pct``
740-
| ``i_gain_pct``
741-
| ``p_gain_pct``
742-
| ``sample_rate_ms``
743-
| ``setpoint``
744-
745-
Note, however, that achieving desirable results this way generally requires
746-
expert-level understanding of the power vs performance tradeoff, so extra care
747-
is recommended when attempting to do that.
748-
749705

750706
.. _LCEU2015: http://events.linuxfoundation.org/sites/events/files/slides/LinuxConEurope_2015.pdf
751707
.. _SDM: http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-system-programming-manual-325384.html
752708
.. _ACPI specification: http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf
753-
.. _PID controller: https://en.wikipedia.org/wiki/PID_controller

0 commit comments

Comments
 (0)