This attribute accepts a range from 0 through 4 where larger values
will also have larger panel power savings.
Using this has a trade off for color accuracy, and it is only applied
when the system is currently operating on battery.
Intentionally the plugin will check what values are already programmed
to the sysfs file to avoid unnecessary writes. Writing the sysfs file
will cause a modeset which isn't necessary if writing the same value twice.
The default values are applied to the profiles that are used in
power-profiles-daemon compatbility. They also match the values used in
that software.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
E.g.:
[variables]
dummy=${f:log:${f:exec:uname}}
Logs the output of the 'uname' command to the TuneD log.
Also added more verbose debug output which can help with functions
debugging. Enable with 'tuned -D'.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
The feature depends on kernel configuration (CONFIG_CPU_IDLE).
While this seems to be commonly enabled on x86, we've seen ARM
systems where it's disabled, and in this case it's perfectly valid
for /dev/cpu_dma_latency to be missing.
Since we cannot opt-out of the PM QoS feature in the cpu plugin, this
case should not be an error.
Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
power-profiles-daemon has the ability to detect battery change events
using upower and to apply different tuned settings based upon whether
plugged into power or not.
In PPD this is used specifically to set the energy performance preference
differently in the 'balanced' profile, but there is no reason that this
concept can't actually apply to all profiles.
Add support for detecting battery change events and apply a profile
specified in ppd.conf for battery in the different PPD states.
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>
This adds a check to instance_acquire_devices to ensure
that the plugin actually supports the requested operation.
Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
Currently instance priorities are only used at startup to sort the
instance classes. To enable dynamic creation of instances, we need
to store the priorities, so new instances can be sorted accordingly.
Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.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>
