Use the new irqbalance plugin instead of a script to set up
irqbalance.
I'm placing the 'irqbalance' instance before the 'script' instance so
that it's executed at the same time as the script, however I don't
think the 'irqbalance' instance needs to be ordered in any specific
way and could be placed almost anywhere.
Resolves: rhbz#1784645
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Use the new irqbalance plugin instead of a script to set up
irqbalance.
Note that I'm not setting priority for the 'irqbalance' instance,
whereas the 'script' instance has a priority of 5. However, this was
added just for initrd image generation in commit 843dc8cf5f
and I don't think the irqbalance instance needs to be ordered in any
specific way.
Resolves: rhbz#1784645
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The irqbalance plugin is a replacement for the bash functions
irqbalance_banned_cpus_setup and irqbalance_banned_cpus_clear. It
configures the banned CPUs in /etc/sysconfig/irqbalance. Then it
restarts irqbalance (if and only if it was previously running).
The banned CPUs can be specified as a CPU list. For example:
[irqbalance]
banned_cpus=2,4,9-13
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Resolves: rhbz#1784645
There should be a way for administrators and testers to force loading of
architecture specific tuning. For example, if there is some specific tuning
for some platforms with specific CPUIDs and the vendor will release new
compatible platform with the new CPUID, there needs to be a way for
administrator to use the tuning on the new platform without waiting for the
Tuned profile update or without the need to customize the profile.
This commit adds two main config options:
uname_string
cpuinfo_string
If unset (commented), which is the default, runtime detection will be used,
i.e. 'uname' will be called and '/proc/cpuinfo' will be read. If set,
content of the variables will be used instead of the runtime detection.
For example by setting:
uname_string = aarch64
It's possible to pretend that Tuned is running on the 64-bit ARM.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
The 'is' operator is used to determine object identity. What we want
to do here instead is a value comparison, i.e. the "==" operator.
With the 'is' operator, the conditions would likely never evaluate to
true.
This fixes errors such as these (they seem to get produced during byte
compilation; you can trigger them just by running Tuned).
/root/tuned/tuned/plugins/plugin_cpu.py:76: SyntaxWarning: "is" with a literal. Did you mean "=="?
if vendor is "GenuineIntel":
/root/tuned/tuned/plugins/plugin_cpu.py:78: SyntaxWarning: "is" with a literal. Did you mean "=="?
elif vendor is "AuthenticAMD" or vendor is "HygonGenuine":
/root/tuned/tuned/plugins/plugin_cpu.py:78: SyntaxWarning: "is" with a literal. Did you mean "=="?
elif vendor is "AuthenticAMD" or vendor is "HygonGenuine":
This fixes commit 29022a0edf.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
This is a minimal viable implementation of a post-loaded profile
feature. It was implemented to satisfy the needs of the
kernel_settings Ansible role.
https://github.com/linux-system-roles/kernel_settings
This feature allows us to apply a profile in a way that is
somewhat separate from the way profiles from the active_profile file
are applied. Namely, the post-loaded profile is always applied after
all the profiles from the active_profile (or more precisely, the
post-loaded profile is always put to the tail of the profile chain
when merging). Also, the post-loaded profile setting is not affected
by running 'tuned-adm profile <some profile>' - the post-loaded
profile remains applied.
The name of the post-loaded profile is stored in
/etc/tuned/post_loaded_profile.
The lack of support for multiple post-loaded profiles was more or less
an arbitrary decision. There are no problems with it, as far as I can
see. However, there is currently no use case for multiple post-loaded
profiles, so I decided to make things easier for our future selves -
it's one less thing to worry about if we need to make changes to the
profile loading logic. We can add support for multiple post-loaded
profiles anytime.
A number of other design decisions went into the
implementation. They are listed here:
https://github.com/redhat-performance/tuned/pull/272
Resolves: rhbz#1798183
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Profile which tunes down I/O activity to the serial console by reducing the
printk value. This should make the serial console more responsive.
This profile is intended to be used as an overlay on other
profiles (e.g. throughput-performance profile), example:
# tuned-adm profile throughput-performance optimize-serial-console
Also minor fixes to the man page quoting.
Resolves: rhbz#1840689
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Currently the 92-tuned.install kernel-install plugin adds the tuned params
to the BLS config files in s390x machines. But the zipl bootloader doesn't
have support for variables, which leads to cmdlines like the following:
root=/dev/mapper/rhel-root crashkernel=auto rd.dasd=0.0.541f rd.dasd=0.0.551f
rd.dasd=0.0.561f rd.dasd=0.0.571f rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap
cio_ignore=all,!condev rd.znet=qeth,0.0.0600,0.0.0601,0.0.0602,layer2=1,portno=0
$tuned_params BOOT_IMAGE=0
Don't modify the BLS snippet since the zipl bootloader doesn't support the
variables and just make the script to exit if the architecture is s390x.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
There can be lower number of arguments than the max limit.
Also fixed definition of functions which wrongly used the API.
I.e. it should work this way:
# exactly 3 arguments
__init__("FUNC", 3, 3)
# max 4 arguments, min 3 arguments (3 - 4 arguments)
__init__("FUNC", 4, 3)
# max 3 arguments (0 - 3 arguments)
__init__("FUNC", 3)
# min 3 arguments (3 - infinity arguments)
__init__("FUNC", 0, 3)
# arbitrary number of arguments (0 - infinity arguments)
__init__("FUNC", 0)
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Also added regex_search_ternary built-in function.
It takes arguments in the following form:
STR1, REGEX, STR2, STR3
If REGEX matches STR1 (re.search is used), STR2 is returned,
if it doesn't match STR3 is returned.
Example:
[variables]
foo=Y
bar=${f:regex_search_ternary:${foo}:\b[y,Y,1,t,T]\b:foo:bar}
It will result in the 'foo' string stored in the '${bar}' variable.
Resolves: rhbz#1797025
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Currently when grub.cfg file is not found, the [bootloader] plugin still
modifies /etc/tuned/bootcmdline file. However, during rollbacks, the settings
applied to that file are not rolled back. This becomes a problem in
(containerized) environments when grub.cfg file does not exist. This patch
will make the behaviour more consistent and unapply the settings in
/etc/tuned/bootcmdline even when no grub.cfg is found.
Signed-off-by: Jiri Mencak <jmencak@users.noreply.github.com>
