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 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>
This will not completely resolve RHEL-60906, because there will be
always race condition if the rename event happens before the instance
is fully initialized, but it should significantly improve the situation.
Drawback is that it can report in the logs device names that shouldn't
be matched by the plugin_net instance, i.e. it matches devices according
to their original names but accesses them with their new names. This
can be confusing. Also in the runtime API (e.g. for removal of the
device from the instance), the original device names have to be used.
For insertion of the device to the instance, new names have to be used.
This can be even more confusing.
Unfortunately, there probably isn't better alternative now, because
for correct operation we would have to handle rename by removal and
addition events. This would require rollback and retune steps which would
lead to very negative performance consequences. Also we would have to
cope with partially tuned devices if the rename event happens during
profile application. It's doable, but it would require big
architectural changes.
The PR also extends internal API, now the plugin instances receive
'instance' as a method parameter.
Also fixed some existing CodeQL warnings.
Resolves: RHEL-60906
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
It may happen that a process gets moved into a blacklisted cgroup
when TuneD is already applying a profile. Postpone the filtering of
processes according to the blacklist to the last possible moment to
minimize the race window.
When setting process affinity fails, re-check whether the process
belongs to a blacklisted cgroup once again and do not report an
error if that's the case.
Resolves: RHEL-72981
