With this builtin function it is possible to write now:
[variables]
pstate=${f:intel_recommended_pstate}
[bootloader]
cmdline_pstate=+intel_pstate=${pstate}
The builtin function will return value: disable|active based on the processor
model and pass the proper intel_pstate value to kernel command line in boot time
................................
Intel recommends to use the intel_pstate CPUFreq driver in active mode with HWP
enabled on Ice Lake and later generations processors.This feature allows dynamically
set intel_pstate based on the processor's model. Currently, users need to create a
tuned override if they want to set intel_pstate to active even for newer generation processors.
For older generation processors setting pstate to active can introduce jitters which were
historically seen around and tested with RHEL-7.4.From IceLake generation, intel has fixed these issues.
Signed-off-by: Sabbir Hasan <sahasan@redhat.com>
Rename the plugin name as so can be used as placeholder for Uncore
settings for other CPU vendors.
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Dynamic tuning is PoC implementation and it can cause many problems
especially with some networks drivers where it can interrupt network
connections and also with modern CPUs where it can worsen power
consumption by limiting CPUs from entering deeper C-states. Now, when
TuneD is going to replace power-profiles-daemon these problems can
accumulate and cause bad user experience.
RHEL disables dynamic tuning downstream for a long time, so follow it
and also disable it by default upstream. People who knows what they are
doing can still enable it.
Fixes#588
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
- add remove parameter to set command
- minor fixes for logging messages
- remove device_module_name
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Add simplistic intel uncore plugin to so that uncore maximum and
minimum frequency can be set.
For example lowering uncore maximum frequency can have significant
impact on the total power consummation of SoC.
Refer to the following link to get details:
https://docs.kernel.org/admin-guide/pm/intel_uncore_frequency_scaling.html
When system with TPMI (Topology Aware Register and PM Capsule Interface)
is detected only devices configured via TPMI are used, since configuring
via deprecated (package/die) interface create conflict on new systems.
Plugin allow to configure frequency per individual uncore units, example
profile config options can look like this:
[intel_uncore_all0] # power save
type=intel_uncore
devices=uncore0*
max_freq_khz=2000000
[intel_uncore_10] # performance
type=intel_uncore
devices=uncore10
min_freq_khz=4000000
[intel_uncore] # for all others save power with little performance cost
max_freq_khz=4600000
For systems where maximum/minimum configured frequency is above/below
the system limits, values are capped to the limit. Wrong configuration
i.e. maximum frequency below minimum frequency is skipped and errors
are logged.
TODO:
- Create matching functions in (tuned/profiles/functions) to allow
to identify cpus belongs to uncore unit as well uncore TPMI unit
based on power domain/package/die.
- Add uncore frequency configuration to basics or specialistic profiles.
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
This adds the [scheduler] plugin option `irq_process`, which
controls whether the plugin performs any tuning of IRQ affinities.
Resolves: RHEL-21923
Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
This change does not attempt to _wifi_set_power_level()
unless /proc/net/wireless exists.
Other changes: fix a typo.
Signed-off-by: Jiri Mencak <jmencak@users.noreply.github.com>
Resolves: RHEL-16966
At this point, the plugin supports setting a single sysfs attribute,
platform_profile.
The 3 basic ACPI platform profiles are low-power, balanced, and
performance. These are mapped to the generic powersave,
balanced, and *-performance TuneD profiles.
The `force_latency` option already supports using C-state IDs/names.
This commit extends the support to the `pm_qos_resume_latency_us` option,
together with the ability to set fallback values (including the special
"n/a" value which disables all C-states).
Resolves: RHEL-21129
