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
79 For example, the ``powersave`` P-state selection algorithm provided by
83 There are two P-state selection algorithms provided by ``intel_pstate`` in the
88 Which of the P-state selection algorithms is used by default depends on the
90 Namely, if that option is set, the ``performance`` algorithm will be used by
91 default, and the other one will be used by default if it is not set.
98 to avoid enabling it by passing the ``intel_pstate=no_hwp`` argument to the
102 select P-states by itself, but still it can give hints to the processor's
107 Even though the P-state selection is carried out by the processor automatically,
135 set to by the platform firmware). This usually causes the processor's
142 feature. It also is used by default with the ``intel_pstate=no_hwp`` argument
153 periodically updated by those utilization update callbacks too.
173 implemented by the generic ``schedutil`` scaling governor except that the
174 utilization metric used by it is based on numbers coming from feedback
178 This algorithm is run by the driver's utilization update callback for the
179 given CPU when it is invoked by the CPU scheduler, but not more often than
199 it is invoked by generic scaling governors when necessary to talk to the
204 scaling governors listed by the ``scaling_available_governors`` policy attribute
209 maximum and minimum operating frequencies supported by the hardware (including
211 the entire range of available P-states is exposed by ``intel_pstate`` to the
215 by the current scaling governor for the given policy).
238 choice going forward. However, that permission is interpreted differently by
240 processors will never use any P-states above the last one set by software for
243 turbo range, even above the one set by software. In other words, on those
255 fact, if one of them is set by software, the processor is not expected to change
270 processor model and can be determined by reading the processor's model-specific
273 threshold effectively becomes a configurable value that can be set by the
317 supporting the HWP feature, which is why they all are supported by
353 Number of P-states supported by the processor (between 0 and 255
357 The value of this attribute is not affected by the ``no_turbo``
373 default), turbo P-states can be set by the driver.
375 attribute (supported by some other scaling drivers) which is replaced
376 by this one.]
414 cause the driver to switch over to the operation mode represented by
436 ``scaling_cur_freq`` attributes are produced by applying a processor-specific
437 multiplier to the internal P-state representation used by ``intel_pstate``.
439 attributes are capped by the frequency corresponding to the maximum P-state that
459 List of P-state selection algorithms provided by ``intel_pstate``.
462 P-state selection algorithm provided by ``intel_pstate`` currently in
466 Frequency of the average P-state of the CPU represented by the given
468 driver's utilization update callback by the CPU scheduler for that CPU.
494 1. All CPUs are affected by the global limits (that is, none of them can be
498 2. Each individual CPU is affected by its own per-policy limits (that is, it
515 P-states within these limits. Otherwise, the limits are taken into account by
516 scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver
521 at all and the only way to set the limits is by using the policy attributes.
531 selection logic by focusing it on performance or on energy-efficiency, or
536 (or the CPU represented by it).
538 The hint can be changed by writing to this attribute.
546 value was set by the platform firmware.
553 [Note that tasks may by migrated from one CPU to another by the scheduler's
564 On the majority of systems supported by ``intel_pstate``, the ACPI tables
565 provided by the platform firmware contain ``_PSS`` objects returning information
568 returned by them).
570 The information returned by the ACPI ``_PSS`` objects is used by the
571 ``acpi-cpufreq`` scaling driver. On systems supported by ``intel_pstate``
573 interface, but the set of P-states it can use is limited by the ``_PSS``
576 On those systems each ``_PSS`` object returns a list of P-states supported by
578 be used by ``intel_pstate`` on the same system, with one exception: the whole
579 `turbo range <turbo_>`_ is represented by one item in it (the topmost one). By
580 convention, the frequency returned by ``_PSS`` for that item is greater by 1 MHz
581 than the frequency of the highest non-turbo P-state listed by it, but the
586 The list of P-states returned by ``_PSS`` is reflected by the table of
587 available frequencies supplied by ``acpi-cpufreq`` to the ``CPUFreq`` core and
588 scaling governors and the minimum and maximum supported frequencies reported by
591 frequency reported by ``acpi-cpufreq`` is higher by 1 MHz than the frequency
592 of the highest supported non-turbo P-state listed by ``_PSS`` which, of course,
593 affects decisions made by the scaling governors, except for ``powersave`` and
598 (possibly multiplied by a constant), then it will tend to choose P-states below
609 returned by ``_PSS`` properly, there may be more than one item corresponding to
613 by ``_PSS``, but that is not sufficient when there are other turbo P-states in
614 the list returned by it.
618 is limited to the ones listed by the ACPI ``_PSS`` objects.
630 processor is supported by it.
647 This option does not work with processors that are not supported by
653 <Active Mode With HWP_>`_ even if it is supported by the processor.
658 supported by the processor.
665 Server", the ACPI ``_PPC`` limits are taken into account by default
681 by ``CPUFreq``, and the other one is the ``pstate_sample`` trace event specific
682 to ``intel_pstate``. Both of them are triggered by ``intel_pstate`` only if
696 ``cpu_frequency`` trace event will be triggered either by the ``schedutil``
697 scaling governor (for the policies it is attached to), or by the ``CPUFreq``