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>
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>
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>
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>
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>
The kernel.shmall and kernel.shmmax parameters were previously set using
a script that calculated their values based on the system's memory size.
However the script was broken for high values of memory size.
The default value of kernel.shmall and kernel.shmmax in RHEL-8 is
18446744073692774399, which is sufficiently high and it's recommended to
use it. So we could simply drop the tuning from the profile, however it
seems better to set the value explicitly so that the profile overrides
any changes that may have been applied to the parameters due to
misconfiguration.
Resolves: rhbz#1708418
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The default value of kernel.sem in RHEL-8 is '32000 1024000000 500
32000', which is much higher than what we currently have in the profile.
It is unnecessary to lower the settings, the RHEL-8 defaults are safe to
use. So we could simply drop the tuning from the profile, however it
seems better to set the value explicitly so that the profile overrides
any changes that may have been applied to the parameter due to
misconfiguration.
Resolves: rhbz#1701394
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The default value of kernel.sem in RHEL-8 is '32000 1024000000 500
32000', which is much higher than what we currently have in the profile.
It is unnecessary to lower the settings, the RHEL-8 defaults are safe to
use. So we could simply drop the tuning from the profile, however it
seems better to set the value explicitly so that the profile overrides
any changes that may have been applied to the parameter due to
misconfiguration.
Resolves: rhbz#1701394
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
As discussed in rhbz#1672213, the sap-hana-vmware profile is not needed
anymore and it only confuses users. Let's drop it.
Resolves: rhbz#1715541
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The force_latency parameter belongs to the cpu plugin, so that's the
section it needs to be in.
Fixes#132
Resolves: rhbz#1569375
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Fallback to the 'powersave' CPU scaling governor if 'ondemand' is
not available. This can happen if the intel_pstate driver is active - at
least on newer kernels, the only available governors are 'powersave' and
'performance' if the driver is active.
As far as we can tell, the 'powersave' governor is the closest to the
'ondemand' governor.
Resolves: rhbz#1679205
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Fallback to the 'powersave' CPU scaling governor if 'conservative' is
not available. This can happen if the intel_pstate driver is active - at
least on newer kernels, the only available governors are 'powersave' and
'performance' if the driver is active.
As far as we can tell, the 'powersave' governor is the closest to the
'conservative' governor.
Resolves: rhbz#1679205
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
kernel.sched_migration_cost_ns=5000000 was being defined here even though it was defined in the included latency-performance profile. Removed to eliminate redundancy.
Tested on an AMD machine with acpi-cpufreq kernel driver providing
ondemand, conservative,... governors.
Without this line, one gets:
tuned.plugins.plugin_cpu: ignoring governor 'conservative' on cpu 'cpu7', it
is not supported
when switching to balanced profile.
With this line you see:
tuned.plugins.plugin_cpu: setting governor 'ondemand' on cpu 'cpu2'
Be careful: Order matters!
tuned seem to read profile config file line by line or section by section
and directly tries to apply things.
If order of these lines are exchanged:
[modules]
cpufreq_conservative=+r
[cpu]
governor=conservative
you fall back to previous error again. Therefore the newly introduced
[modules] section is not put at the end, but nearly at top.
It updates the KVM modprobe file if its content differs from what's
supported on the current system. It may look a bit over-engineered, but
it's done this way to lower the possibility of race condition.
Resolves: rhbz#1649408
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Disabling the ksm and ksmtuned services during boot seems to cause
problems, so do it only once when the profile is first applied and
reenable the services only when full rollback is required.
Resolves: rhbz#1622239
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The default tuned profile for an oVirt cluster is "virtual-host".
Recently, testing at customer sites and performance labs has shown
that "latency-performance" yields better results. This patch makes
virtual-host profile identical to latency-performance. This seems
better than uniting them since this way we maintain the possibility
to tweak them in different ways in the future according to further
findings.
Change-Id: I1a64fac22364b17de1279a3e1f37a6b7eb0fe61b
Bug-Url: https://bugzilla.redhat.com/1588932
Signed-off-by: Ori_Liel <oliel@redhat.com>
The rt-entsk application, part of newer rt-setup packages,
worksaround a latency issue with static key
IPI's. What it does it:
/*
* Open a socket, and enable timestamping on it.
*
* This is to avoid Chrony from changing timestamping
* user count from 0->1 and vice-versa, causing
* static key enable/disable IPIs.
*
*/
Start/stop the systemctl service from the realtime-virtual-host
and realtime-virtual-guest profiles.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
KSM disable code is reimplementing systemctl mask command.
Note only that, but it seems a race is possible where the ksm
services may be starting at the same time as disable_ksm()
is running. I believe the mask command should fix that.
There's an important difference in this new version: we don't
try to start KSM when switching away from the cpu-partitioning
profile. This means KSM will probably remain disabled until
the next reboot.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
As noted in the bugzilla ticket
https://bugzilla.redhat.com/show_bug.cgi?id=1554851
The QEMU I/O thread can interrupt the time measurement
of the timer. To avoid this problem, only
pin the vCPU thread.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Reviewed-and-Tested-by: Luiz Capitulino <lcapitulino@redhat.com>
v2:
- Use unix sockets (Luiz)
- Proper numeric output (Luiz)
In the cpu-partitioning profile, IRQ affinity change is already done
as part of the 'isolated_cores' option of the scheduler plugin, so
calling defirqaffinity is, at best, redundant. So let's remove the call.
In the realtime* profiles, it's essentially the same, except that tuna
was used instead of isolated_cores. So let's use built-in functionality
instead of tuna and drop calls to defirqaffinity.
Resolves: rhbz#1590937
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Previously the irqbalance config was not modified if setting the affinity
of at least one IRQ failed. That does not make much sense to me - it can
result in irqbalance assigning isolated CPUs to IRQs, even if it can be
prevented.
Even if affinity cannot be changed for any of the present IRQs,
hypothetically it can happen (I think) that new hardware is hotplugged,
and the affinity of its IRQ can be changed. So let's always modify the
irqbalance config for good measure.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The code was completely broken. Jaroslav and I think the purpose
of the code was to check that the files
/sys/module/kvm/parameters/kvmclock_periodic_sync
/sys/module/kvm_intel/parameters/ple_gap
contain "0", which we think is the (at least intended) result of
profiles/functions:setup_kvm_mod_low_latency(). So I'm fixing it
to do that.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Since Linux 4.13 the value "powersave" in the x86_energy_perf_policy
program has been renamed to "power". Let's try both values when
applying the powersave profile.
Resolves: rhbz#1508468
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
A common source of confusion within tuned is the lack of suffix
on the readahead specification in the throughput-performance
tuned.conf. This confusion is resolved, in general, by comparing
the value, for example, to blockdev or lvdisplay output. Avoid
future end-user confusion by adding a comment to the
throughput-performance tuned.conf file, explaining that the default
is in KiB, and noting the allowance of a sector suffix as well.
Signed-off-by: John Pittman <jpittman@redhat.com>
script.sh has been using variable names in different ways,
in different scopes: when using variables at all. Fix all that.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Profile loading is broken since commit b532e9291d, due to
a small typo in the new function name.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Also fixed cpu-partitioning profile script not to break irqbalance
configuration file in case of defirqaffinity failure.
Resolves: rhbz#1536476
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
