The disk plugin checks each device for hdparm
support during initialization. When using many disk
devices, this can lead to unwanted delays in profile
application.
This change makes the hdparm check lazy by postponing
it to the moment when hdparm is actually needed, i.e.,
during dynamic tuning or when setting spindown/apm.
Each device is checked at most once - the plugin now stores
the sets of hdparm-supported devices and hdparm-unsupported
devices).
Resolves: RHEL-6891
The video plugin checks each device for hdparm
support during initialization. When using many disk
devices, this can lead to unwanted delays in profile
application.
This change makes the hdparm check lazy by postponing
it to the moment when hdparm is actually needed, i.e.,
during dynamic tuning or when setting spindown/apm.
Each device is checked at most once - the plugin now stores
the sets of hdparm-supported devices and hdparm-unsupported
devices).
Resolves: RHEL-6891
If the CPU supports hwp_epp, we should always be able to access
EPB via its sysfs knob, so we don't have to check if we have
x86_energy_perf_policy because we don't need it to manipulate EPB.
In some situations it may be desirable to check if a file write is
necessary by comparing the new file content with the existing one
(e.g., when the write always causes an inter-processor interrupt).
This commit adds an option to perform such a check in `write_to_file`.
If it succeeds, the write is skipped.
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>
In rare cases, 'lap-mode' and 'no-turbo' files may be
empty. Do not attempt to convert their content into
integers. Instead check if it's directly equal to "1"
(after stripping whitespace).
If TuneD was simply off before the restart, we can then
switch the profile using the dbus method. Otherwise we
fallback to a profile switch via setting the active_profile
file (where we do not check for success).
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>
We can use `read_file` and `write_to_file` to handle all manipulation
of sysctl parameters. This does not change the behavior of _read_sysctl
and _write_sysctl, but it alters some of their debug/error messages.
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.
