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>
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>
