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>
This option disables the TSC clocksource watchdog
for isolated CPUs (which avoids interruptions
by the per-CPU clocksource watchdog timer).
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Variables in force_latency, min_perf_pct, max_perf_pct and no_turbo
options were not being expanded. Fix it.
Fixes#203
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
In the kernel table of exit latencies of various CPUs the worst
exit latency for C1 seems to be 3 us, so increase the backup
value latency requirement to 3 us to match the worst C1 exit
latency.
Related: rhbz#1737628
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Now multiple profiles can be included by:
[main]
include=profile1;profile2
Also comma "," can be used instead of the semicolon ";".
No escaping is done, so it's assumed there will be no comma or semicolon
in the profile name.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
For sap-hana and virtual-host profiles used state3 (i.e. usually C3)
C-state in latency specification instead of the hardcoded value 70 us,
i.e.:
force_latency=cstate.id:3|70
Also dropped obsoleted TODO note from the plugin_cpu.
Related: rhbz#1737628
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Maximal latency can be now specified multiple ways:
- directly in usec (this is the same as before), e.g. for 10 us:
force_latency = 10
- as an ID of maximal cstate allowed, e.g. for the kernel state1:
force_latency = cstate.id:1
- as a name (case sensitive) of maximal cstate allowed, e.g. for the state named C1:
force_latency = cstate.name:C1
It is also possible to specify multiple fallback values separated by '|', e.g.:
force_latency = cstate.name:C6|cstate.id:4|10
This will try to obtain latency of cstate named C6, if it fails (e.g.
there is no such cstate), it will try kernel state4 and if it also fails
it finally fallbacks to 10 us.
This commit also changes force_latency settings of latency-performance
profile to:
force_latency=cstate.id:1|1
I.e. it tries kernel state1 and fallbacks to 1 us.
Resolves: rhbz#1737628
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
It fixed the following problem e.g. the profile:
[sysctl]
kernel.pid_max=>131072
and if kernel.pid_max is already 131072 Tuned shows traceback.
Resolves: rhbz#1739418
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
RHEL will include a backport of the kernel patch
"do not raise timer softirq unconditionally (spinlockless version)"
(https://lkml.org/lkml/2019/4/15/1215), but disabled by default.
Enable it in realtime-virtual-{host/guest} profiles as it decreases
maximum cyclictest latency.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
