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>
Realtime profiles require to restrict irqbalance too. Apply them to
the realtime profile so that realtime-virtual-{host|guest} can benefit
from that too.
Signed-off-by: Peter Xu <peterx@redhat.com>
Due to commit d4038a7e64, if a script fails to execute or its exit
code is non-zero, no subsequent scripts are executed. This seems
logically wrong and it causes problems especially during rollback as some
tunings may not be reverted due to this behaviour. Also, it appears it
was not the intention of that commit to change this behaviour - the
intention rather seems to have been to make _call_scripts return
success/error information for use by the verification mechanism.
So let's aggregate the success/error information instead.
Related: https://github.com/redhat-performance/tuned/pull/194
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
So that QEMU uses the in kernel irqchip.
Original patch provided by Luiz Capitulino <lcapitulino@redhat.com>.
Resolves: rhbz#1554458
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
