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 performance 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 This attribute is present only if the value exposed by it is the same
371 The value of this attribute is not affected by the ``no_turbo``
380 This attribute is present only if the value exposed by it is the same
390 default), turbo P-states can be set by the driver.
392 attribute (supported by some other scaling drivers) which is replaced
393 by this one.]
431 cause the driver to switch over to the operation mode represented by
441 Lake or Coffee Lake desktop CPU model. By default, energy-efficiency
459 ``scaling_cur_freq`` attributes are produced by applying a processor-specific
460 multiplier to the internal P-state representation used by ``intel_pstate``.
462 attributes are capped by the frequency corresponding to the maximum P-state that
482 List of P-state selection algorithms provided by ``intel_pstate``.
485 P-state selection algorithm provided by ``intel_pstate`` currently in
489 Frequency of the average P-state of the CPU represented by the given
491 driver's utilization update callback by the CPU scheduler for that CPU.
517 1. All CPUs are affected by the global limits (that is, none of them can be
521 2. Each individual CPU is affected by its own per-policy limits (that is, it
539 by scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver
544 at all and the only way to set the limits is by using the policy attributes.
552 processor's internal P-state selection logic by focusing it on performance or on
558 (or the CPU represented by it).
560 The hint can be changed by writing to this attribute.
568 value was set by the platform firmware.
579 [Note that tasks may by migrated from one CPU to another by the scheduler's
590 On the majority of systems supported by ``intel_pstate``, the ACPI tables
591 provided by the platform firmware contain ``_PSS`` objects returning information
594 returned by them).
596 The information returned by the ACPI ``_PSS`` objects is used by the
597 ``acpi-cpufreq`` scaling driver. On systems supported by ``intel_pstate``
599 interface, but the set of P-states it can use is limited by the ``_PSS``
602 On those systems each ``_PSS`` object returns a list of P-states supported by
604 be used by ``intel_pstate`` on the same system, with one exception: the whole
605 `turbo range <turbo_>`_ is represented by one item in it (the topmost one). By
606 convention, the frequency returned by ``_PSS`` for that item is greater by 1 MHz
607 than the frequency of the highest non-turbo P-state listed by it, but the
612 The list of P-states returned by ``_PSS`` is reflected by the table of
613 available frequencies supplied by ``acpi-cpufreq`` to the ``CPUFreq`` core and
614 scaling governors and the minimum and maximum supported frequencies reported by
617 frequency reported by ``acpi-cpufreq`` is higher by 1 MHz than the frequency
618 of the highest supported non-turbo P-state listed by ``_PSS`` which, of course,
619 affects decisions made by the scaling governors, except for ``powersave`` and
624 (possibly multiplied by a constant), then it will tend to choose P-states below
635 returned by ``_PSS`` properly, there may be more than one item corresponding to
639 by ``_PSS``, but that is not sufficient when there are other turbo P-states in
640 the list returned by it.
644 is limited to the ones listed by the ACPI ``_PSS`` objects.
656 processor is supported by it.
675 This option does not work with processors that are not supported by
681 supported by the processor.
685 hardware-managed P-states (HWP) feature is supported by the processor.
692 Server", the ACPI ``_PPC`` limits are taken into account by default
708 by ``CPUFreq``, and the other one is the ``pstate_sample`` trace event specific
709 to ``intel_pstate``. Both of them are triggered by ``intel_pstate`` only if
723 ``cpu_frequency`` trace event will be triggered either by the ``schedutil``
724 scaling governor (for the policies it is attached to), or by the ``CPUFreq``