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>
This reverts commit d0b43e8b74.
This reverts https://github.com/redhat-performance/tuned/pull/216.
The change is completely unnecessary. The following regex (mentioned
in the commit message of the original commit)
^ID_MODEL=SD_MMC$.*^ID_MODEL_ID=0316$
can be simply changed like this
^ID_MODEL=SD_MMC$(.|\n)*^ID_MODEL_ID=0316$
and it'll match the desired string without re.DOTALL
ID_MODEL=SD_MMC
ID_MODEL_ENC=SD\x2fMMC\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
ID_MODEL_ID=0316
So it seems completely unnecessary to introduce this user-visible
change in behaviour.
Also, the change would in fact make matching strings on a single line
harder, because the following regex
^ID_MODEL=.*SD_MMC$
would also match the following multi-line string with re.DOTALL
ID_MODEL=HDD
ID_MODEL_ID=0316
COMMENT=ULTRA_SD_MMC
A big thanks to Jaroslav Škarvada for discovering this.
https://github.com/redhat-performance/tuned/pull/216#issuecomment-557915251
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Previously, if the grub.cfg patching code ran into a grub.cfg file
that was empty, all subsequent grub.cfg files would get skipped and
would not be patched. This behaviour doesn't make much sense to me. We
should skip empty grub.cfg files and patch all the non-empty ones.
Resolves: rhbz#1622646
Update checking if EPB is supported so that it works with recent
versions of the x86_energy_perf_policy tool. Newer versions of
x86_energy_perf_policy, unlike older versions, exit with a zero exit
code even if the CPU doesn't support EPB. Newer versions of the tool
give no ouput on stdout if EPB is not supported, so check for that.
In the future, we might like to determine if EPB is supported by
searching /proc/cpuinfo for specific CPU flags. However the solution
described in the previous paragraph should work just fine for now.
Resolves: rhbz#1690929
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
In order to allow matching multiple parameter-value pairs in a single
regex, we need to use re.DOTALL, because the parameter-value pairs are
on separate lines. Consider the following regex:
^ID_MODEL=SD_MMC$.*^ID_MODEL_ID=0316$
Previously it would not much a string such as the following:
ID_MODEL=SD_MMC
ID_MODEL_ENC=SD\x2fMMC\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
ID_MODEL_ID=0316
Now it does match.
It should be noted that this change is not entirely
backwards-compatible. Some user-written regexes can now start to match
where they shouldn't. For example the following regex will now match
even if 'ID_MODEL_ID' and '0316' are on different lines.
ID_MODEL_ID.*0316
The primary motivation for this change is making the udev matcher
behave the same as the cpuinfo matcher that will be written to resolve
rhbz#1748965.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Changing the SMP affinity of some IRQs is not supported. The semantics
of ignore_missing is that unsupported tunings are not treated as
errors during verification. IRQ SMP affinity being unchangeable can be
regarded as an unsupported tuning, so skip verification of these IRQs
when ignore_missing is set.
The code assumes that the IRQ numbers point to the same device/event
throughout the Tuned run time. We might need to break this assumption
in the future (or maybe not; I haven't looked into how IRQ numbers are
allocated). Either way, the assumption is already present in the code
- rollback assumes the same thing.
Resolves: rhbz#1729936
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
