Lines Matching refs:performance

17 :doc:`CPU performance scaling subsystem <cpufreq>` in the Linux kernel
25 than just an operating frequency or an operating performance point (see the
30 uses frequencies for identifying operating performance points of CPUs and
59 active mode, it uses its own internal performance scaling governor algorithm or
60 allows the hardware to do performance scaling by itself, while in the passive
62 a certain performance scaling algorithm. Which of them will be in effect
91 active mode: ``powersave`` and ``performance``. The way they both operate
97 Namely, if that option is set, the ``performance`` algorithm will be used by
122 HWP + ``performance``
128 internal P-state selection logic is expected to focus entirely on performance.
132 the EPP/EPB to a value different from 0 ("performance") via ``sysfs`` in this
147 internal P-state selection logic to be less performance-focused.
162 ``powersave`` or ``performance``, depending on the ``scaling_governor`` policy
167 ``performance``
192 every 10 ms. Like in the ``performance`` case, the hardware configuration
256 performance scaling control for that core and put it into turbo P-states of its
299 used relative to ACPI-based CPU performance scaling (see
343 cores differing by the maximum turbo P-state, performance vs power characteristics,
346 and it assumes the HWP performance units to be the same for all CPUs in the
347 system, so a given HWP performance level always represents approximately the
348 same physical performance regardless of the core (CPU) type.
355 one core, ``intel_pstate`` assigns performance-based priorities to CPUs. Namely,
356 the priority of a given CPU reflects its highest HWP performance level which
365 This approach maximizes performance in the majority of cases, but unfortunately
397 HWP performance level, multiplied by 1024, to the highest HWP performance level
398 of the most performant CPU in the system, which works because the HWP performance
419 There is a performance domain in it for every CPU in the system and the cost
420 values for these performance domains have been chosen so that running a task on
457 maximum supported performance level (the highest supported :ref:`turbo
466 maximum supported performance level (the highest supported :ref:`turbo
516 of this mechanism is to improve performance).
639 effective performance depends on whether the platform supports per core
640 P-states, hyper-threading is enabled and on current performance requests
642 effective performance can be more than the policy limits set on a CPU, if
643 other CPUs are requesting higher performance at that moment. Even with per
645 is requesting higher performance, the other siblings will get higher
646 performance than their policy limits.
668 processor's internal P-state selection logic by focusing it on performance or on
673 Current value of the energy vs performance hint for the given policy
682 They represent different energy vs performance hints and should be
696 load-balancing algorithm and if different energy vs performance hints are
698 issues it is better to set the same energy vs performance hint for all CPUs
708 that can be used for CPU performance scaling (refer to the ACPI specification
714 the ``acpi-cpufreq`` driver uses the same hardware CPU performance scaling
736 ``performance``.
804 Take ACPI ``_PPC`` performance limits into account.