Add missing options profile_info, auto_profile and profile mode in the OPTIONS section of the man page.
Resolves: rhbz#2075774
Signed-off-by: Vaibhav Nagare <vnagare@redhat.com>
AsciiDoc documentation for all the TuneD plug-ins directly in the source
code. This will allow auto-generation of the TuneD plug-in
documentation. Documenting new plug-ins and plug-in features needs to
be compulsory now.
Documentation for txqueuelen and mtu options in net plugin provided by
Jan Zerdik.
Signed-off-by: Jiri Mencak <jmencak@users.noreply.github.com>
Signed-off-by: Jan Zerdik <jzerdik@redhat.com>
AWS Nitro instances need special tuning for NVMe devices:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/nvme-ebs-volumes.html#timeout-nvme-ebs-volumes
[sysfs]
/sys/module/nvme_core/parameters/io_timeout=4294967295
/sys/module/nvme_core/parameters/max_retries=10
This tuning should probably be moved to Cloud Provider-specific profiles
once the functionality is implemented.
Signed-off-by: Jiri Mencak <jmencak@users.noreply.github.com>
We already disable the clocksource watchdog, it's there to double-check
whether clock results are coherent between reads. But a new reliability
test was introduced in recent kernels[1], tracking tsc drift between
CPUs[2]. It works by programming timers on all CPUs, including isolated
ones, and checks whether the tsc was adjusted in between runs. This
introduces unwarranted latency on real time systems. So let's promote
tsc to 'reliable', which disables both checks.
There shouldn't be any impact on old nor new setups. First, this test
didn't exist in the past, so any eventual drift was left uncorrected.
Second, most telco and HPC use-cases will make heavy use of tsc in
user-space, and its reliability is already assumed in the system's
design.
[1] c7719e793478 x86/tsc: Add a timer to make sure TSC_adjust is always
checked
[2] Generally caused by rogue BIOSes adjusting the tsc on a CPU and not
doing so on the rest
Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Previously, if there wasn't syspurpose (usually provided by the
subscription-manger), all the 'syspurpose_role' matches were ignored.
This wasn't correct, because it didn't allow enforcing of the system
role. Now in such cases the syspurpose_role is matched against the
empty string, i.e. the empty string means 'no syspurpose role or
syspurpose error'.
E.g. previously the following rule matched in case of no syspurpose:
something_that_matched
syspurpose_role=.*atomic.*
Now it doesn't match, but the previous behavior can be still
emulated by e.g.:
something_that_matched
syspurpose_role=(.*atomic.*)|^$
Also the error about the missing syspurpose module is now displayed only
once (for each 'recommend' call) and not multiple times for each
recommend rule.
Resolves: rhbz#2030580
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
To optimize process name matching, the regexes of all groups are combined
into one (r1)|(r2)|..., and after matching the capture is used to determine
which of the original regexes matched. This means that the individual
group regexes must not contain any captures. The current solution replaces
all "(" and ")" with "\(" and "\)".
Thus, if we want a group to match "thread(1|2|3)", this will turn into
"thread\(1|2|3\)", a regex that matches the three strings "thread(1",
"2" and "3)", which is definitely not what is intended.
This is fixed by instead replacing any "(" by "(?:", making the group
non-capturing. Replacement is not performed if the "(" is preceded by "\"
or follwed by "?".
Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
