Commit 068928e ("Add support for controlling amd-pstate core
performance boost") started setting the newly-introduced `boost`
parameter in the balanced and powersave profiles, but forgot to do the
same in the performance profiles. The net result was that transitioning
directly from the powersave profile to a performance profile would leave
boosting disabled.
Fix this by setting boost=1 explictly in all performance-oriented
profiles (i.e., those with a min_perf_pct of 100).
Fixes: 068928e ("Add support for controlling amd-pstate core performance boost")
Same for dirty_background_ratio and dirty_background_bytes.
Using both the ratio and the bytes is not compatible with
the current profile inheritance implementation, because it
is not possible for dirty_bytes in a child profile to override
dirty_ratio in its parent profile.
Resolves: RHEL-101578
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>
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.
According to the performance team measurements the sched_ tuning
should be dropped in several profiles.
Resolves: rhbz#1957829
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
New kernels (5.13 and newer) moved some sched_ and numa_ knobs from
the sysctl to the debugfs, thus add and abstract these knobs under the
scheduler plugin. With help of this abstraction it will write
the tuning to the correct place according to the kernel used.
Example:
[scheduler]
sched_migration_cost_ns = 500000
Will work on the old kernel the same way as:
[sysctl]
kernel.sched_migration_cost_ns = 500000
I.e. it will write '500000' to the:
/proc/sys/kernel/sched_migration_cost_ns
And on the new kernel it will write '500000' to the:
/sys/kernel/debug/sched/migration_cost_ns
Also updated TuneD profiles.
Resolves: rhbz#1952687
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Update sysctl tunings in the latency-performance profile based on
feedback from the performance team.
Resolves: rhbz#1779759
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
In the kernel table of exit latencies of various CPUs the worst
exit latency for C1 seems to be 3 us, so increase the backup
value latency requirement to 3 us to match the worst C1 exit
latency.
Related: rhbz#1737628
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Maximal latency can be now specified multiple ways:
- directly in usec (this is the same as before), e.g. for 10 us:
force_latency = 10
- as an ID of maximal cstate allowed, e.g. for the kernel state1:
force_latency = cstate.id:1
- as a name (case sensitive) of maximal cstate allowed, e.g. for the state named C1:
force_latency = cstate.name:C1
It is also possible to specify multiple fallback values separated by '|', e.g.:
force_latency = cstate.name:C6|cstate.id:4|10
This will try to obtain latency of cstate named C6, if it fails (e.g.
there is no such cstate), it will try kernel state4 and if it also fails
it finally fallbacks to 10 us.
This commit also changes force_latency settings of latency-performance
profile to:
force_latency=cstate.id:1|1
I.e. it tries kernel state1 and fallbacks to 1 us.
Resolves: rhbz#1737628
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Added new tuned-adm functionality 'profile_info'. It has optional parameter
'profile_name'. If called without parameter, active profile is used.
It outputs name of the profile it is querying, profile summary, and profile
description. If there is no profile summary or description available it
outputs empty string(s).
Extended tuned-adm 'list' functionality. It now displays profile summary
in the list (if available).
Added summary to profiles.
Extended D-Bus API to support the new feature and for better Cockpit support:
- Added 'profile_info' method. It gets profile_name argument and it queries
the requested profile for information. If profile_name is empty string it
queries the active/selected profile. It returns tuple of the following
format (status, profile_name, summary, description), where status is
boolean. If it is False, the query mechanism failed and the other fields
don't contain valid data
- Added 'profiles2' method. It's extension of 'profiles' method. It returns
list of tuples. Tuples have following format:
(profile_name, profile_summary)
Related: rhbz#1228356
Fixes: #46
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
The following intel_pstate parameters are now supported:
min_perf_pct
max_perf_pct
no_turbo
Resolves: rhbz#996722
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
From the performance team feedback, the C1 should be used
by default and the C0 let to be optional.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
