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>
Make sure the isolated_cores and no_balance_cores variables are
defined before any of the variables that use them are defined. This
enforces a certain ordering of variable expansions so that child
profiles can set the variables directly in the profile (tuned.conf),
e.g.:
[main]
include=cpu-partitioning
[variables]
isolated_cores=3
Resolves: rhbz#1781664
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Intel's new Speed Select Technology (SST) is a process power management
technology introduced by Intel that allows for throughput and per-core
performance configurations and optimizations such as allowing for
prioritization of workloads on specific cores by sacrificing performance
on other cores.
Intel has released several CascadeLake processors, commonly referred to
as CascadeLake-N, with this technology and will introduce further SST
related technologies in the next few years.
These new technologies require the disabling of the intel-pstate driver
configuration in tuned as it may interfere with the user chosen per-core
configurations of SST.
Add a new SST profile to tuned for general use.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Joe Mario <jmario@redhat.com>
Update sysctl tunings in the latency-performance profile based on
feedback from the performance team.
Resolves: rhbz#1779759
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
This allows writing e.g.:
[cpu]
force_latency=cstate.name:XYZ|None
In this case if C-state with name XYZ doesn't exist force_latency
will be evaluated to 'None' and nothing will be set and no
error will be reported. If '|None' is omitted, error will be
reported.
Another example:
[cpu]
force_latency=None
Here, it will also set nothing and no error will be reported.
When 'None' is encountered it stops parsing the latency, so writing
'None|1' will also result in no latency set. Both 'none' and 'None' can
be used interchangeably with the same effect.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
The last callers using defirqaffinity.py had been nuked by this commit:
c2dfc1f
Before fully ripping the script out, it should be marked deprecated
for some time.
Consider the following:
profile_1:
[cpu]
force_latency=10
no_turbo=1
[disk]
readahead=4098
If you want to include it in profile_2 and just drop the force_latency
option now you can write:
[main]
include=profile_1
[cpu]
drop=force_latency
Previously, you had to use the replace option and add all other options
which were used in the inherited profiles like:
[main]
include=profile_1
[cpu]
replace=true
no_turbo=1
There can be named multiple options in the drop. As the delimiter comma
',' or semicolon ';' can be used, spaces are ignored, e.g.:
[cpu]
drop=force_latency, no_turbo
Fixes: #227
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
The reapply_sysctl functionality was originally added to address
rhbz#1302953, which was about Tuned overriding sysctl config files
from /etc, which was deemed undesirable. The bug said nothing about
sysctl config files from /usr/lib/sysctl.d, /lib/sysctl.d or
/usr/local/lib/sysctl.d.
Having sysctl configs from /usr override Tuned profiles causes
problems (rhbz#1759597). Also, it seems reasonable for Tuned profiles
to override sysctl configs from /usr - a Tuned profile is often
explicitly chosen by the user, whereas sysctl configs from /usr are
provided by system packages whether the user wants them or not.
Also, in RHEL-6, tuned used to ignore sysctl config files from /usr,
as far as I can tell.
Resolves rhbz#1759597
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
To fix rhbz#1774645 and rhbz#1702724, we need to make the
`Controller.reload` operation behave the same as a Tuned restart even
in the case when Tuned is running but no profile is applied. To
achieve that, we must not `return False` from `reload()` when Daemon
is not running.
I'm not aware of any specific purpose the `return False` could serve,
other than perhaps making sure that running reload after `tuned-adm
off` does not result in the recommended profile being applied. This
case is handled in commit 5d8ef2c009, so I think it should be safe
now to drop the `return`.
Resolves: rhbz#1774645
Resolves: rhbz#1702724
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
To fix rhbz#1774645 and rhbz#1702724, we need to make the
`Controller.reload` operation behave the same as a Tuned restart even
in the case when Tuned is running but no profile is applied. If we did
that, while setting automatic profile mode on `tuned-adm off` (as it
is currently done), we would end up with a behaviour where `tuned-adm
off` followed by controller reload would result in the recommended
profile being applied.
We agreed with Jaroslav that this behaviour wouldn't make sense, so we
instead decided to change the behaviour of `tuned-adm off` followed by
Tuned *restart*. Previously, it would result in the recommended
profile being applied (which doesn't make much sense to us either). So
we decided to change `tuned-adm off`, so that even after restart,
Tuned runs with no profile applied, i.e. making `tuned-adm off` set
manual profile mode.
Related: rhbz#1774645
Related: rhbz#1702724
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The reload_profile_config() method can pass through a TunedException
when the requested profile does not exist, or is invalid. We need to
catch it and log the error.
Resolves: rhbz#1774645
Resolves: rhbz#1702724
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Previously, when unit tests were run, python would leave behind files
with bytecompiled modules. It's not useful, it just clutters the
repository. And it could potentially lead to problems - it seems to
have lead to some problem for me earlier today when running git bisect to
find out when `make test` started failing.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Also added cpuinfo_check builtin function.
It's possible to write now:
[variables]
cannonalake_cpuinfo=.*\bGenuineIntel\b.*
cannonlake_uname=x86_64
[cpu_cannonlake]
type=cpu
cpuinfo_regex=${cannonlake_cpuinfo}
uname_regex=${cannonlake_uname}
force_latency=C1
[disk_cannonlake]
type=disk
cpuinfo_regex=${cannonlake_cpuinfo}
uname_regex=${cannonlake_uname}
readahead=4092
...
And the tuning will be applied only on machines which have
'GenuineIntel' string in the /proc/cpuinfo and x86_64 architecture (from
uname). Both 'cpuinfo_regex' and 'uname_regex' are optional - if not
used it has the same effect as if matching regex is used. This example
used variables but it also works without it.
Also cpuinfo_check builtin function was added, so it's possible to write
the following now:
[main]
include=${f:cpuinfo_check:\bGenuineIntel\b:intel_profile:other_profile}
It tries to match the regex '\bGenuineIntel\b' in the /proc/cpuinfo
and if it matches it includes 'intel_profile', if not it includes
'other_profile'. If colon ':' needs to be used in the regex, it needs
to be escaped, i.e.: '\:'
It's even possible to combine it with the generic profiles, e.g.:
[main]
include=base_profile${f:cpuinfo_check:\bGenuineIntel\b:,intel_profile}
It will always include 'base_profile' and if the cpuinfo matches
GenuineIntel it also adds the intel_profile. More variants are possible,
the generic syntax is:
${f:cpuinfo_check:REGEX1:STR1:REGEX2:STR2:...[:FALLBACK_STR]}
It returns STR1 if REGEX1 matches, STR2 if REGEX2 matches, and
FALLBACK_STR if nothing matches. If there is no FALLBACK_STR it returns
empty string on no match. It exits on the first match found and
no more regexes are processed in such case
TODO:
Current limitation: Variables are not expanded in the include, so it's
not possible to write:
[main]
include=${f:cpuinfo_check:${regex}:test}
[variables]
regex=TEST
Resolves: rhbz#1748965
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
