Lines Matching refs:by
21 For the processors supported by ``intel_pstate``, the P-state concept is broader
23 `LinuxCon Europe 2015 presentation by Kristen Accardi <LCEU2015_>`_ for more
25 by ``intel_pstate`` internally follows the hardware specification (for details
29 frequencies are involved in the user space interface exposed by it, so
34 that. Some functionality of the core is limited by that.
36 Since the hardware P-state selection interface used by ``intel_pstate`` is
77 For example, the ``powersave`` P-state selection algorithm provided by
81 There are two P-state selection algorithms provided by ``intel_pstate`` in the
86 Which of the P-state selection algorithms is used by default depends on the
88 Namely, if that option is set, the ``performance`` algorithm will be used by
89 default, and the other one will be used by default if it is not set.
96 to avoid enabling it by passing the ``intel_pstate=no_hwp`` argument to the
100 select P-states by itself, but still it can give hints to the processor's
105 Even though the P-state selection is carried out by the processor automatically,
133 set to by the platform firmware). This usually causes the processor's
140 feature. It also is used by default with the ``intel_pstate=no_hwp`` argument
151 periodically updated by those utilization update callbacks too.
171 implemented by the generic ``schedutil`` scaling governor except that the
172 utilization metric used by it is based on numbers coming from feedback
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
197 it is invoked by generic scaling governors when necessary to talk to the
202 scaling governors listed by the ``scaling_available_governors`` policy attribute
207 maximum and minimum operating frequencies supported by the hardware (including
209 the entire range of available P-states is exposed by ``intel_pstate`` to the
213 by the current scaling governor for the given policy).
236 choice going forward. However, that permission is interpreted differently by
238 processors will never use any P-states above the last one set by software for
241 turbo range, even above the one set by software. In other words, on those
253 fact, if one of them is set by software, the processor is not expected to change
268 processor model and can be determined by reading the processor's model-specific
271 threshold effectively becomes a configurable value that can be set by the
315 supporting the HWP feature, which is why they all are supported by
351 Number of P-states supported by the processor (between 0 and 255
355 The value of this attribute is not affected by the ``no_turbo``
371 default), turbo P-states can be set by the driver.
373 attribute (supported by some other scaling drivers) which is replaced
374 by this one.]
412 cause the driver to switch over to the operation mode represented by
434 ``scaling_cur_freq`` attributes are produced by applying a processor-specific
435 multiplier to the internal P-state representation used by ``intel_pstate``.
437 attributes are capped by the frequency corresponding to the maximum P-state that
457 List of P-state selection algorithms provided by ``intel_pstate``.
460 P-state selection algorithm provided by ``intel_pstate`` currently in
464 Frequency of the average P-state of the CPU represented by the given
466 driver's utilization update callback by the CPU scheduler for that CPU.
485 1. All CPUs are affected by the global limits (that is, none of them can be
489 2. Each individual CPU is affected by its own per-policy limits (that is, it
498 P-states within these limits. Otherwise, the limits are taken into account by
499 scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver
504 at all and the only way to set the limits is by using the policy attributes.
514 selection logic by focusing it on performance or on energy-efficiency, or
519 (or the CPU represented by it).
521 The hint can be changed by writing to this attribute.
529 value was set by the platform firmware.
536 [Note that tasks may by migrated from one CPU to another by the scheduler's
547 On the majority of systems supported by ``intel_pstate``, the ACPI tables
548 provided by the platform firmware contain ``_PSS`` objects returning information
551 by them).
553 The information returned by the ACPI ``_PSS`` objects is used by the
554 ``acpi-cpufreq`` scaling driver. On systems supported by ``intel_pstate``
556 interface, but the set of P-states it can use is limited by the ``_PSS``
559 On those systems each ``_PSS`` object returns a list of P-states supported by
561 be used by ``intel_pstate`` on the same system, with one exception: the whole
562 `turbo range <turbo_>`_ is represented by one item in it (the topmost one). By
563 convention, the frequency returned by ``_PSS`` for that item is greater by 1 MHz
564 than the frequency of the highest non-turbo P-state listed by it, but the
569 The list of P-states returned by ``_PSS`` is reflected by the table of
570 available frequencies supplied by ``acpi-cpufreq`` to the ``CPUFreq`` core and
571 scaling governors and the minimum and maximum supported frequencies reported by
574 frequency reported by ``acpi-cpufreq`` is higher by 1 MHz than the frequency
575 of the highest supported non-turbo P-state listed by ``_PSS`` which, of course,
576 affects decisions made by the scaling governors, except for ``powersave`` and
581 (possibly multiplied by a constant), then it will tend to choose P-states below
592 returned by ``_PSS`` properly, there may be more than one item corresponding to
596 by ``_PSS``, but that is not sufficient when there are other turbo P-states in
597 the list returned by it.
601 is limited to the ones listed by the ACPI ``_PSS`` objects.
613 processor is supported by it.
630 This option does not work with processors that are not supported by
636 <Active Mode With HWP_>`_ even if it is supported by the processor.
641 supported by the processor.
648 Server", the ACPI ``_PPC`` limits are taken into account by default
664 by ``CPUFreq``, and the other one is the ``pstate_sample`` trace event specific
665 to ``intel_pstate``. Both of them are triggered by ``intel_pstate`` only if
679 ``cpu_frequency`` trace event will be triggered either by the ``schedutil``
680 scaling governor (for the policies it is attached to), or by the ``CPUFreq``