From: Sean Christopherson <seanjc@google.com>
To: bugzilla-daemon@kernel.org
Cc: kvm@vger.kernel.org
Subject: Re: [Bug 218259] New: High latency in KVM guests
Date: Wed, 13 Dec 2023 08:54:40 -0800 [thread overview]
Message-ID: <ZXng-hPIH8bav7iU@google.com> (raw)
In-Reply-To: <bug-218259-28872@https.bugzilla.kernel.org/>
On Tue, Dec 12, 2023, bugzilla-daemon@kernel.org wrote:
> The affected hosts run Debian 12; until Debian 11 there was no trouble.
> I git-bisected the kernel and the commit which appears to somehow cause the
> trouble is:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f47e5bbbc92f5d234bbab317523c64a65b6ac4e2
Huh. That commit makes it so that KVM keeps non-leaf SPTEs, i.e. upper level page
table structures, when zapping/unmapping a guest memory range. The idea is that
preserving paging structures will allow for faster unmapping (less work) and faster
repopulation if/when the guest faults the memory back in (again, less work to create
a valid mapping).
The only downside that comes to mind is that keeping upper level paging structures
will make it more costly to handle future invalidations as KVM will have to walk
deeper into the page tables before discovering more work that needs to be done.
> Qemu command line: See below.
> Problem does *not* go away when appending "kernel_irqchip=off" to the -machine
> parameter
> Problem *does* go away with "-accel tcg", even though the guest becomes much
> slower.
Yeah, that's expected, as that completely takes KVM out of the picture.
> All affected guests run kubernetes with various workloads, mostly Java,
> databases like postgres und a few legacy 32 bit containers.
>
> Best method to manually trigger the problem I found was to drain other
> kubernetes nodes, causing many pods to start at the same time on the affected
> guest. But even when the initial load settled, there's little I/O and the
> guest is like 80% idle, the problem still occurs.
>
> The problem occurs whether the host runs only a single guest or lots of other
> (non-kubernetes) guests.
>
> Other (i.e. not kubernetes) guests don't appear to be affected, but those got
> way less resources and usually less load.
The affected flows are used only for handling mmu_notifier invalidations and for
edge cases related to non-coherent DMA. I don't see any passthrough devices in
your setup, so that rules out the non-coherent DMA side of things.
A few things to try:
1. Disable KSM (if enabled)
echo 0 > /sys/kernel/mm/ksm/run
2. Disable NUMA autobalancing (if enabled):
echo 0 > /proc/sys/kernel/numa_balancing
3. Disable KVM's TDP MMU. On pre-v6.3 kernels, this can be done without having
to reload KVM (or reboot the kernel if KVM is builtin).
echo N > /sys/module/kvm/parameters/tdp_mmu
On v6.3 and later kernels, tdp_mmu is a read-only module param and so needs
to be disable when loading kvm.ko or when booting the kernel.
There are plenty more things that can be tried, but the above are relatively easy
and will hopefully narrow down the search significantly.
Oh, and one question: is your host kernel preemptible?
next prev parent reply other threads:[~2023-12-13 16:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-12 16:37 [Bug 218259] New: High latency in KVM guests bugzilla-daemon
2023-12-13 16:54 ` Sean Christopherson [this message]
2023-12-13 16:54 ` [Bug 218259] " bugzilla-daemon
2023-12-14 7:14 ` bugzilla-daemon
2023-12-18 17:07 ` Sean Christopherson
2023-12-14 7:15 ` bugzilla-daemon
2023-12-14 7:16 ` bugzilla-daemon
2023-12-18 17:07 ` bugzilla-daemon
2024-01-11 15:55 ` Sean Christopherson
2023-12-19 14:09 ` bugzilla-daemon
2023-12-19 15:16 ` Sean Christopherson
2023-12-19 15:16 ` bugzilla-daemon
2024-01-11 15:55 ` bugzilla-daemon
2024-01-16 13:29 ` bugzilla-daemon
2024-01-17 1:05 ` Sean Christopherson
2024-01-17 1:05 ` bugzilla-daemon
2024-01-17 14:04 ` bugzilla-daemon
2024-11-05 0:27 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZXng-hPIH8bav7iU@google.com \
--to=seanjc@google.com \
--cc=bugzilla-daemon@kernel.org \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox