The PREEMPT_RT upstream tree [1] is reintroducing a per-CPU kthread for
handling timer expiry named ktimers/${cpu}, and RHEL-RT is following this
approach [2].
The recommended priority tuning for that kthread is to simply match that of
ksoftirqd, which is what is implemented here.
Note that ktimersoftd is the predecessor of ktimers, and isn't present on
RT kernels newer than v5.0.19-rt11 / RHEL-RT 7.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=2122220
Resolves: rhbz#2122220
Signed-off-by: Valentin Schneider <vschneid@redhat.com>
The kernel tunable fs.aio-max-nr specifies the maximum number of events
specified on the io_setup() call for all currently active aio contexts.
On large systems this causes issues with the io_setup() call failing
with EAGAIN. Libvirt already increases this setting to 1048576:
96e99e4948/src/remote/libvirtd.sysctl
The only potential drawback of a larger limit is that a malicious users
could issue parallel io_setup() requests to cause the kernel to set
aside memory.
Signed-off-by: Jiri Mencak <jmencak@users.noreply.github.com>
According to testing done by the kernel QE and performance teams,
the sched_* tunables should be dropped in several profiles.
The openshift-control-plane profile is based on other profiles
which have already dropped these tunables (network-latency,
throughput-performance).
The calc_isolated_cores function expands to the list of cores to
isolate. It accepts optional argument which specifies how many cores
from each socket reserve for housekeeping. If not specified, one core
from each socket is reserved for housekeeping.
Example:
Machine with 2 sockets, each 4 cores, using the following user variable
configuration file, e.g. /etc/tuned/realtime-variables.conf:
isolated_cores=${f:calc_isolated_cores:2}
It will expand to:
isolated_cores=2, 3, 6, 7
I.e. cores 0, 1 and 4, 5 will be used for housekeeping.
Also updated the TuneD profiles to use this builtin function for
isolated_cores preset.
Resolves: rhbz#2093847
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
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>
The following is now parsed differently:
[bootloader]
cmdline =+
Previously it was parsed as operator "=" adding symbol "+" to the cmdline,
now it is parsed as operator "=+" adding empty string "".
For the previous behaviour the leading "+" can now be escaped. It works the
following way:
cmdline =+ -> operator "=+" adding ""
cmdline =\+ -> operator "=" adding "+"
cmdline =\\+ -> operator "=" adding "\+"
Non leading escaping is ignored, e.g.:
cmdline =ab\+ -> operator "=" adding "ab\+"
Similarly for the operator "=-".
Also the arguments are now correctly escaped when further processed by
TuneD and the following problems should be now fixed:
cmdline =\n -> corruption of the /etc/tuned/bootcmdline with newlines
cmdline =\k -> TuneD traceback
cmdline =\1 -> operator "=" adding "TUNED_BOOT_CMDLINE="
There could be more undesired effects and that's why the escaping different
from the previously described leading escaping "\\", "\+", "\-" should be
now ignored.
Resolves: rhbz#1884472
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
As *args is tuple we cannot change its values. This cause exception for example when calling dbus without sudo and fallback for tuned-adm, but this behavior at least confusing.
Signed-off-by: Jan Zerdik <jzerdik@redhat.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>
