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>
The x86_energy_perf_policy program changed its interface in the 4.13
kernel. The value 'power' now has to be used instead of 'powersave'.
Resolves: rhbz#1508468
Helper state file for cpu-partitioning script was moved to /run/tuned.
Code for flags manipulation has been simplified.
The /run/tuned directory is explicitly cleared upon uninstallation
of Tuned to get rid of all leftovers / helper files before the reboot.
Added STORAGE_PERSISTENT variable pointing to /var/lib/tuned into
functions to be consistent.
Related: rhbz#1497182
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
As cpu-partitioning doesn't use isolcpus=, isolated CPUs can incur
very high latency due to load balancing performed by the kernel
scheduler.
This patch introduces a new configuration option called
no_rebalance_cores=. This options allow users to set a range
of CPUs to have load balancing disabled from /proc. It is
expected that users will only disable load balancing on CPUs
which run PMD threads (or vCPU threads running PMD threads),
since disabling this for all isolated CPUs can cause certain
performance problems for OpenStack.
Here are some numbers:
- Without using no_rebalance_cores=, I can easily get 40us+
in load balancing isolated CPUs:
<...>-14140 [001] 1656.121155: funcgraph_entry: + 43.927 us | rebalance_domains();
<...>-14140 [001] 1660.117150: funcgraph_entry: + 41.587 us | rebalance_domains();
<...>-14140 [001] 1658.119152: funcgraph_entry: + 41.565 us | rebalance_domains();
<...>-14140 [001] 1668.110140: funcgraph_entry: + 40.539 us | rebalance_domains();
- When using no_rebalance_cores=, the maximum latency I
get is ~ 1us:
<...>-2440 [012] 1705.078076: funcgraph_entry: 1.024 us | rebalance_domains();
<...>-2438 [008] 2021.065218: funcgraph_entry: 0.995 us | rebalance_domains();
<...>-2447 [010] 2223.057289: funcgraph_entry: 0.991 us | rebalance_domains();
IMPORTANT: 10 minutes run only.
This solution was developed by Andrew Theurer <atheurer@redhat.com>,
I'm merely integrating it into the profile.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
KSM is enabled by default when the qemu-kvm-common-rhev package is
installed. We don't want KSM to run in KVM-RT nor cpu-partitioning
hosts, as it can cause spikes or packet drops.
This series disables KSM in those profiles when they are activated.
Likewise, we re-enable KSM when the profile is de-activated in
case it's enabled by default in systemd.
Luiz Capitulino (3):
profiles: functions: add functions to disable/enable KSM
realtime-virtual-host: disable KSM
cpu-partitioning: disable KSM
profiles/cpu-partitioning/script.sh | 2 ++
profiles/functions | 37 ++++++++++++++++++++++++++++++++
profiles/realtime-virtual-host/script.sh | 3 +++
3 files changed, 42 insertions(+)
--
2.9.5
Return-Path: lcapitulino@redhat.com
Received: from zmta04.collab.prod.int.phx2.redhat.com (LHLO
zmta04.collab.prod.int.phx2.redhat.com) (10.5.81.11) by
zmail22.collab.prod.int.phx2.redhat.com with LMTP; Tue, 3 Oct 2017 15:54:02
-0400 (EDT)
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
by zmta04.collab.prod.int.phx2.redhat.com (Postfix) with ESMTP id 46F2FD0310
for <jskarvad@mail.corp.redhat.com>; Tue, 3 Oct 2017 15:54:02 -0400 (EDT)
Received: by smtp.corp.redhat.com (Postfix)
id 3FBC860F82; Tue, 3 Oct 2017 19:54:02 +0000 (UTC)
Delivered-To: jskarvad@redhat.com
Received: from localhost (ovpn-117-159.phx2.redhat.com [10.3.117.159])
by smtp.corp.redhat.com (Postfix) with ESMTP id 3A51A60F81;
Tue, 3 Oct 2017 19:53:59 +0000 (UTC)
From: Luiz Capitulino <lcapitulino@redhat.com>
To: jskarvad@redhat.com
Cc: kvm-rt@redhat.com
Subject: [PATCH 1/3] profiles: functions: add functions to disable/enable KSM
Date: Tue, 3 Oct 2017 15:53:50 -0400
Message-Id: <20171003195352.22910-2-lcapitulino@redhat.com>
In-Reply-To: <20171003195352.22910-1-lcapitulino@redhat.com>
References: <20171003195352.22910-1-lcapitulino@redhat.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
They will be used by the next commits.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Prefix DPM states with 'dpm-' to prevent future name collisions.
Also, change the state in powersave profiles to 'battery' - there's
no such DPM state as powersave.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Use net plugin to disable large receive offload in sap-hana-vmware profile.
This also fixes rollback of the setting - previously, after unapplying
the profile, LRO would always be set to 'on', irrespectively of the
original setting.
The network interfaces which should have LRO disabled must be listed
in /etc/tuned/sap-hana-vmware-variables.conf, e.g. like this:
sap_hana_vmware_nic=eth0
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Now, in addition to the already supported Radeon power methods, it also
supports:
radeon_powersave=DPM
where DPM can be 'battery', 'balanced', or 'performance'.
It also supports fallback, so one can write:
radeon_powersave=balanced, auto
where it tries 'balanced' DPM profile and if it fails or is not
supported it fallbacks to the non DPM 'auto' profile.
As delimiters colon, semilocon, comma or whitespace can be used.
It also switched upstream profiles to prefer DPM.
https://github.com/redhat-performance/tuned/pull/32
Related: rhbz#1417659
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Tuna is already executed in the realtime profile which is included by
the realtime-virtual-host/guest profiles, there is no need to execute
it twice. Also fixed minor whitespace inconsistency.
Related: rhbz#1472840
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Also removed the parameter from the realtime profile, because it already
includes the network-latency profile.
Resolves: rhbz#1451073
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
From 63e5ebfe0c71c5e6d0613c4d8327b2a6f3fba7ba Mon Sep 17 00:00:00 2001
From: Luiz Capitulino <lcapitulino@redhat.com>
Date: Fri, 19 May 2017 14:42:06 -0400
Subject:
The realtime guest profile uses the RT kernel default priority
assignment for the ksoftird, rcuc, and ktimersoftd kernel threads,
which is:
17 FF 2 [rcuc/1] *
19 FF 1 [ktimersoftd/1] *
20 TS - [ksoftirqd/1] *
This doesn't allow running a PMD thread with fifo:1 in the
guest, since this will starve ktimersoftd and ksoftirqd if
those threads ever become runnable.
The solution is to use the same priority assigment we use
in the host where we've been running PMD threads with
fifo:1 priorities without problems. This assignment is:
151 FF 4 [rcuc/15] *
153 FF 3 [ktimersoftd/15] *
154 FF 2 [ksoftirqd/15] *
This patch just copies the [scheduler] section from the
host profile.
Resolves: rhbz#1452357
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
