This allows writing e.g.:
[cpu]
force_latency=cstate.name:XYZ|None
In this case if C-state with name XYZ doesn't exist force_latency
will be evaluated to 'None' and nothing will be set and no
error will be reported. If '|None' is omitted, error will be
reported.
Another example:
[cpu]
force_latency=None
Here, it will also set nothing and no error will be reported.
When 'None' is encountered it stops parsing the latency, so writing
'None|1' will also result in no latency set. Both 'none' and 'None' can
be used interchangeably with the same effect.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Update checking if EPB is supported so that it works with recent
versions of the x86_energy_perf_policy tool. Newer versions of
x86_energy_perf_policy, unlike older versions, exit with a zero exit
code even if the CPU doesn't support EPB. Newer versions of the tool
give no ouput on stdout if EPB is not supported, so check for that.
In the future, we might like to determine if EPB is supported by
searching /proc/cpuinfo for specific CPU flags. However the solution
described in the previous paragraph should work just fine for now.
Resolves: rhbz#1690929
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Variables in force_latency, min_perf_pct, max_perf_pct and no_turbo
options were not being expanded. Fix it.
Fixes#203
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
For sap-hana and virtual-host profiles used state3 (i.e. usually C3)
C-state in latency specification instead of the hardcoded value 70 us,
i.e.:
force_latency=cstate.id:3|70
Also dropped obsoleted TODO note from the plugin_cpu.
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>
This patch fixes (at least) the following race conditions:
1. If a device is attached while iterating assigned devices, the
MonitorObserver thread can attempt to insert the newly attached
device to the assigned_devices set while the set is being iterated,
which results in the following exception:
RuntimeError: Set changed size during iteration
2. Some devices can be missed when applying a tuning - devices are enumerated
(i.e., Plugin._init_devices() gets called) before udev device monitoring is
started (hotplug.Plugin._hardware_events_init() gets called), so devices
that appear between these two actions are not tuned.
3. Device monitoring is stopped too late, which can result in some tunings
not being unapplied after stopping a profile. This can happen for devices
that get added during profile rollback after unit_manager.stop_tuning()
gets called, but before unit_manager.destroy_all() gets called.
4. It can happen that tuning is applied twice for a device if it is added
during profile activation, e.g. after unit_manager.create() is called in
Daemon._thread_code(), but before unit_manager.start_tuning() is called.
Apart from unnecessarily applying the tuning twice, it can result in
overwriting saved original settings for the device and hence our inability
to properly roll back our changes to the settings.
5. The observer thread can attempt to use load_monitor before it's created
in Plugin._instance_init(), which can result in AttributeError.
Hopefully it doesn't introduce new race conditions :).
The fix is to:
1. rearrange the sequence of certain actions,
2. separate Instance.devices to two separate sets: processed_devices
and assigned_devices.
processed_devices are never iterated when the MonitorObserver thread
is running (*), so the first problem described above cannot happen.
The set is used to store devices, which have already been tuned.
The assigned_devices set is now the set of devices that are going
to be tuned. The set can only be accessed by the main thread.
(*) Except when verifying tuning - this is fixed in a follow-up patch
I tried to separate the changes into more digestable patches, but I
couldn't figure out how.
Resolves: rhbz#1592743
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The 'governor' option of the 'cpu' plugin now supports specifying
multiple governors. The governors are separated using '|' (the '|'
character is meant to represent a logical 'or' operator; we already use
the same syntax for the 'energy_perf_bias' option). Tuned will set
the first governor that is available on the system.
For example, with the following profile, Tuned will set the 'ondemand'
governor, if it's available. If it's not available, but the 'powersave'
governor is available, 'powersave' will be set. If neither of them are
available, the governor will not be changed.
[cpu]
governor=ondemand|powersave
Resolves: rhbz#1679205
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
This avoids wrong warning about a missing intel tool (x86_energy_perf_bias)
Remember arch and x86 CPU vendor to allow arch/vendor specific CPU tunings
in the future
Support specifying alternative Energy Performance Bias values.
The values are separated using the '|' character. For example,
if you have the following in your profile:
[cpu]
energy_perf_bias=powersave|power
then tuned will try to set EPB to 'powersave', and if that fails,
it will try to set it to 'power'.
Resolves: rhbz#1508468
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Fix verification of Energy Performance Bias on Linux 4.13+.
In Linux 4.13, the value strings accepted by the x86_energy_perf_policy
program changed.
Resolves: rhbz#1508468
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
This fixes Pylint errors such as the following:
tuned/logs.py:39: [E1003(bad-super-call), TunedLogger.__init__] \
Bad first argument 'self.__class__' given to super()
This prevents infinite recursion errors, see
https://stackoverflow.com/a/18208725
This does introduce name duplication, but when we drop python2 support
in the future, we can use super() without arguments.
Take the ignore_missing parameter into account in @command_get methods
so that error messages are not logged for missing files.
In some @command_get methods the ignore_missing parameter is not used,
because e.g. it is not applicable or the parameter is handled elsewhere
in the code.
Resolves: rhbz#1451435
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Don't log error in commands.execute() if MSR_IA32_ENERGY_PERF_BIAS
is not supported. A message with level WARN is already logged
afterwards:
WARNING tuned.plugins.plugin_cpu: your CPU doesn't support
MSR_IA32_ENERGY_PERF_BIAS, ignoring CPU energy performance bias
Resolves: rhbz#1443182
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
With systemd full rollback is done if Tuned is terminated by user or profile
is changed. It is not done if Tuned is terminated due to system
shutdown / reboot. Without systemd full rollback is done only if profile
is changed.
Renamed profile_switch parameter to full_rollback where appropriate.
Also fixed various checks for command not found.
Resolves: rhbz#1421286
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
A new option 'devices_udev_regex' can be used in profile
configuration to specify devices to which a plugin instance
should be applied.
The option can contain a python regular expression, as specified
in https://docs.python.org/2/library/re.html#regular-expression-syntax.
The expression is effectively matched against the output of
udevadm info --query=property -n <device_path>
If the option 'devices_udev_regex' is specified, the 'devices' option
is ignored. If it is not specified, then the matching is done the same
way as previously, i.e. against 'devices'.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The _device attribute should always be the same as the union of
_assigned_devices and _free_devices, therefore it's redundant.
Its existence in my opinion brings only confusion and a potential
source of inconsistencies.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The sampling rate determines how frequently the governor checks to tune the
CPU. The sampling_down_factor is a tunable that multiplies the sampling rate
when the CPU is at its highest clock frequency thereby delaying load
evaluation and improving performance. Allowed values for
sampling_down_factor are 1 to 100000.
Usage:
[cpu]
sampling_down_factor = 1
Recommended setting for jitter reduction:
sampling_down_factor = 100
Original idea of adding support for this knob to Tuned came from
Akshay Adiga <akshay.adiga@linux.vnet.ibm.com>
This patch also removes cpupower support from Tuned. It seems
that cpupower tool changes it's output format time to time, and parsing
it in Tuned becomes harder and harder. Morever the current parser in Tuned
didn't handle the recent cpupower correctly. It's much easier to just query
sysfs than supporting multiple versions of cpupower.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
There is no need to save and restore intel pstate attributes which aren't
changed by tuned profile.
Resolves: rhbz#1252156
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
If there is no scaling governor/driver, the CPU is silently skipped when setting
governor.
Related: rhbz#1212836
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Added following functions:
cpulist2hex - converts CPU list to hexadecimal mask, takes arbitrary number of
arguments, each argument can also contain "compact values",
e.g.: "${f:cpulist2hex:0-3,4:5-6}".
hex2cpulist - converts hexadecimal mask to CPU list, takes one argument,
the hexadecimal mask.
cpus_online - checks whether CPUs from the list (which is formatted the same
way as with cpulist2hex) are online, returns only those which
are online.
Example:
[variables]
cpus = ${f:hex2cpulist:0x0000001f}
online = ${f:cpus_online:${cpus}}
Related: rhbz#1225135
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
They were intended to be class methods and that's why there
were defined with the 'cls' parameter, but they actually
weren't class methods.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
The verify command verifies whether the current system settings matches
activated profile. It also writes all settings from the active profile
with the current / expected values to the log. It is good for checking
what is exactly set and what changed during the run.
Currently custom commands and plugin_scheduler are not supported.
Resolves: rhbz#1150047
Fixes: #34
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
This plugin can be used to add parameters to kernel (boot/dracut)
command line. Currently only grub2 bootloader is used and reboot
is required to apply the tunings. The tuning can be only unloaded
by profile change followed by reboot.
It patches grub.cfg at runtime and installs /etc/grub.d/00_tuned
grub2 template. So it's possible to regenerate grub.cfg by
grub2-mkconfig and the tuning persists.
It also patches /etc/default/grub and adds tuned_params grub2 variable
to GRUB_CMDLINE_LINUX. This is probably the only way how to get
variables into kernel command line in grub.cfg. Nothing else is added to
/etc/default and it's patched if the plugin is used for the first
time. It's re-patched on plugin initialization only if the tuned_params
variable is missing.
On subsequent invocation only the tuned_params grub2 variable and
grub.cfg are changed.
Example of use:
[bootloader]
cmdline=quiet
This adds "quiet" parameter to the kernel boot command line (reboot
is required).
EFI is also supported. By default it autodetects redhat and fedora
directories (in this order). Nothing else is touched. If you have
different EFI system and your grub.cfg location is not auto-detected
or your grub.cfg is located on different place you can specify
the grub.cfg location manually:
[bootloader]
grub2_cfg_file=CUSTOM_PATH/grub.cfg
cmdline=quiet
This has precedence over auto-detection. This is used for runtime
patching. In case it is not set correctly, the grub.cfg patching
will not work, but you can still regenerate the config by hand by
grub2-mkconfig.
Resolves: rhbz#1044111
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Made tuned error messages less verbose, but more descriptive if running without
debug option. Also made class from the tuned.utils.commands helper functions.
Its logging can be enabled / disabled.
Resolves: rhbz#1068699
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>
This change moves a lot of logic into the plugins, namely
the enumeration, seizing, and releasing of the devices.
However it allows the plugins to control the process in
more detail. This will be also utilised when tuning the
devices, which were dynamically added into the system.
WATCH OUT: only cpu plugin has been updated
