Lines Matching full:by
24 For the processors supported by ``intel_pstate``, the P-state concept is broader
26 LinuxCon Europe 2015 presentation by Kristen Accardi [1]_ for more
28 by ``intel_pstate`` internally follows the hardware specification (for details
31 frequencies are involved in the user space interface exposed by it, so
36 that. Some functionality of the core is limited by that.
38 Since the hardware P-state selection interface used by ``intel_pstate`` is
59 allows the hardware to do preformance scaling by itself, while in the passive
60 mode it responds to requests made by a generic ``CPUFreq`` governor implementing
83 For example, the ``powersave`` P-state selection algorithm provided by
87 There are two P-state selection algorithms provided by ``intel_pstate`` in the
92 Which of the P-state selection algorithms is used by default depends on the
94 Namely, if that option is set, the ``performance`` algorithm will be used by
95 default, and the other one will be used by default if it is not set.
102 to avoid enabling it by passing the ``intel_pstate=no_hwp`` argument to the
106 select P-states by itself, but still it can give hints to the processor's
111 Even though the P-state selection is carried out by the processor automatically,
141 set to by the platform firmware). This usually causes the processor's
152 recognized by it. [Note that ``intel_pstate`` will never refuse to work with
160 periodically updated by those utilization update callbacks too.
180 implemented by the generic ``schedutil`` scaling governor except that the
181 utilization metric used by it is based on numbers coming from feedback
185 This algorithm is run by the driver's utilization update callback for the
186 given CPU when it is invoked by the CPU scheduler, but not more often than
205 processors that are not recognized by it if HWP is prevented from being enabled
211 it is invoked by generic scaling governors when necessary to talk to the
216 scaling governors listed by the ``scaling_available_governors`` policy attribute
221 maximum and minimum operating frequencies supported by the hardware (including
223 the entire range of available P-states is exposed by ``intel_pstate`` to the
227 by the current scaling governor for the given policy).
250 choice going forward. However, that permission is interpreted differently by
252 processors will never use any P-states above the last one set by software for
255 turbo range, even above the one set by software. In other words, on those
267 fact, if one of them is set by software, the processor is not expected to change
282 processor model and can be determined by reading the processor's model-specific
285 threshold effectively becomes a configurable value that can be set by the
364 Number of P-states supported by the processor (between 0 and 255
368 The value of this attribute is not affected by the ``no_turbo``
384 default), turbo P-states can be set by the driver.
386 attribute (supported by some other scaling drivers) which is replaced
387 by this one.]
425 cause the driver to switch over to the operation mode represented by
435 Lake or Coffee Lake desktop CPU model. By default, energy-efficiency
452 ``scaling_cur_freq`` attributes are produced by applying a processor-specific
453 multiplier to the internal P-state representation used by ``intel_pstate``.
455 attributes are capped by the frequency corresponding to the maximum P-state that
475 List of P-state selection algorithms provided by ``intel_pstate``.
478 P-state selection algorithm provided by ``intel_pstate`` currently in
482 Frequency of the average P-state of the CPU represented by the given
484 driver's utilization update callback by the CPU scheduler for that CPU.
510 1. All CPUs are affected by the global limits (that is, none of them can be
514 2. Each individual CPU is affected by its own per-policy limits (that is, it
532 by scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver
537 at all and the only way to set the limits is by using the policy attributes.
545 processor's internal P-state selection logic by focusing it on performance or on
551 (or the CPU represented by it).
553 The hint can be changed by writing to this attribute.
561 value was set by the platform firmware.
572 [Note that tasks may by migrated from one CPU to another by the scheduler's
583 On the majority of systems supported by ``intel_pstate``, the ACPI tables
584 provided by the platform firmware contain ``_PSS`` objects returning information
587 returned by them).
589 The information returned by the ACPI ``_PSS`` objects is used by the
590 ``acpi-cpufreq`` scaling driver. On systems supported by ``intel_pstate``
592 interface, but the set of P-states it can use is limited by the ``_PSS``
595 On those systems each ``_PSS`` object returns a list of P-states supported by
597 be used by ``intel_pstate`` on the same system, with one exception: the whole
598 `turbo range <turbo_>`_ is represented by one item in it (the topmost one). By
599 convention, the frequency returned by ``_PSS`` for that item is greater by 1 MHz
600 than the frequency of the highest non-turbo P-state listed by it, but the
605 The list of P-states returned by ``_PSS`` is reflected by the table of
606 available frequencies supplied by ``acpi-cpufreq`` to the ``CPUFreq`` core and
607 scaling governors and the minimum and maximum supported frequencies reported by
610 frequency reported by ``acpi-cpufreq`` is higher by 1 MHz than the frequency
611 of the highest supported non-turbo P-state listed by ``_PSS`` which, of course,
612 affects decisions made by the scaling governors, except for ``powersave`` and
617 (possibly multiplied by a constant), then it will tend to choose P-states below
628 returned by ``_PSS`` properly, there may be more than one item corresponding to
632 by ``_PSS``, but that is not sufficient when there are other turbo P-states in
633 the list returned by it.
637 is limited to the ones listed by the ACPI ``_PSS`` objects.
649 processor is supported by it.
668 This option does not work with processors that are not supported by
674 supported by the processor.
678 hardware-managed P-states (HWP) feature is supported by the processor.
685 Server", the ACPI ``_PPC`` limits are taken into account by default
701 by ``CPUFreq``, and the other one is the ``pstate_sample`` trace event specific
702 to ``intel_pstate``. Both of them are triggered by ``intel_pstate`` only if
716 ``cpu_frequency`` trace event will be triggered either by the ``schedutil``
717 scaling governor (for the policies it is attached to), or by the ``CPUFreq``