If TuneD-appended kargs are present and do not match
the kargs to be appended, we should remove them. This
can happen if there was no profile rollback, e.g.,
when using the no-daemon mode.
Resolves: RHEL-86814
The bootloader plugin claims that it does not mess
with existing kernel parameters; make sure we adhere
to that also for rpm-ostree systems:
1. Only append a new karg if the same key=value pair
does not already appear in kernel parameters. If we would
duplicate it, it would not be possible to determine which
one to delete when unapplying the profile.
2. Do not delete existing key=value pairs when the profile
adds a karg with another value for the key. A single key can
appear multiple times in the kernel parameter list with different
values.
Also make sure new kargs are added exactly in the order in which
they appear in the profile. This is especially important for kargs
related to hugepages.
Resolves: RHEL-45836
Timeout in seconds to maximally wait until udev settles. If set to value
bigger than 0, it will either wait until udev settles or the timeout
occurs. Disable with 0.
Resolves: RHEL-88238
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
During profile loading if the device is assigned to the instance but it
isn't processed yet by the main thread and the remove event fires, TuneD
may try to remove the device from the free list, because it wrongly assumes
that the device is unassigned. With this workaround it shouldn't traceback
in such cases, but there may be still some errors when it tries to tune the
removed device in the main thread. We currently cannot do much about it.
The add/rename udev events should be mostly safe, because there are two
threads - the main thread and the udev callback thread. The udev
callback thread is processing udev events sequentially one by one and it
shouldn't break the main thread data when processing the add/rename
events. It would be better to have one worker thread for it, but it
would require quite a big redesign.
Also the cleanup phase was improved, because now it firstly unsubscribes
the udev events and then it continues with the cleanup which should
minimise problems of udev events firing during the profile unload.
Resolves: RHEL-83827
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Without the redirect to /dev/null, an error message would
be reported in TuneD logs on aarch64 machines, which do not
have the kernel module.
Resolves: RHEL-79943
Without exporting the grub variables, they are only available in the
main grub menu[0]. When descending in a submenu (like in default Debian for
example), tuned_* variable are expanded to the empty string and, so,
tuned kernel cmdline tuning is effectively disabled.
With the export, variables are available in submenus and tuned tuning is
applied as expected.
[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094201#10
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Previously, the parser state would be shared, creating races
when two threads would attempt to expand functions in strings
at the same time (e.g., when a device was hotplugged during
TuneD initialization).
The change requires minor refactoring: the function `Repository`
class is now the one providing the expansion API to the `Variables`
class instead of the original `Functions` class (now renamed to
`Parser` and newly created for each expansion).
Resolves: RHEL-75773
The `PluginLoader` class is used as an interace implemented by
all kinds of repositories: of profile plugins, functions, monitors.
While these are all technically "plug-in", the naming is confusing.
The commit also updates the `load_all_plugins` method of the class
(now `load_all_classes`) to use the class loader parameters
(prefix, namespace) instead of hardcoded ones.
Parsing ethtool output has been broken for several years, since `ethtool -c`
started producing a line resembling `CQE mode RX: n/a TX: n/a`.
This prevents setting any [net] coalesce= options, which log
`tuned.plugins.plugin_net: unknown coalesce parameter(s): {'CQE mode RX'}`.
Substituting `cqe-mode-rx:` for `CQE mode RX:` resolves the issue,
although there is a conflict with the `adaptive-tx` workaround
which prevents us from supporting `cqe-mode-tx` directly.
Do not attempt to address that issue as part of this change.
Fixes#726.
Signed-off-by: Ryan Zoeller <ryan.zoeller@aliaro.com>
First, always prefer schedutil for balanced/powersave. On platforms
where this governor is available, this enables Energy-Aware-Scheduling
which offers the best power efficiency and performance combination.
There is absolutely no reason to use another governor by default in the
"balanced" profile on these systems, in particular.
Second, swap around "conservative" and "ondemand". "conservative" is
supposed to be lower power and higher latency. The commit that made this
change [1] tested on a single server platform (10 years ago), but came
to the wrong conclusion. Dividing the throughput by power numbers of
that commit, "conservative" did in fact provide better performance/watt,
which is the intent of lower-power modes. The fact that it also
happened to provide better overall performance than "ondemand" is
probably an artifact of suboptimal power-management behavior or a
flawed test.
[1] b2897d9c1c
Signed-off-by: Hector Martin <marcan@marcan.st>
Not all platforms can offline CPUs. On those that can't, there is no
"online" attribute. Default to online in that case.
Signed-off-by: Hector Martin <marcan@marcan.st>
