]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
ARM: KVM: Yield CPU when vcpu executes a WFE
authorMarc Zyngier <marc.zyngier@arm.com>
Tue, 8 Oct 2013 17:38:13 +0000 (18:38 +0100)
committerJiri Slaby <jslaby@suse.cz>
Thu, 30 Apr 2015 09:14:57 +0000 (11:14 +0200)
commita05353acef600b2629d76a049515de66e73459c1
treea037e1e312f9adca21ac17d649836520344e600b
parent1c8eb115f4394d13cb907f6ffb976640becdb13e
ARM: KVM: Yield CPU when vcpu executes a WFE

commit 1f5580986a3667e9d67b65d916bb4249fd86a400 upstream.

On an (even slightly) oversubscribed system, spinlocks are quickly
becoming a bottleneck, as some vcpus are spinning, waiting for a
lock to be released, while the vcpu holding the lock may not be
running at all.

This creates contention, and the observed slowdown is 40x for
hackbench. No, this isn't a typo.

The solution is to trap blocking WFEs and tell KVM that we're
now spinning. This ensures that other vpus will get a scheduling
boost, allowing the lock to be released more quickly. Also, using
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT slightly improves the performance
when the VM is severely overcommited.

Quick test to estimate the performance: hackbench 1 process 1000

2xA15 host (baseline): 1.843s

2xA15 guest w/o patch: 2.083s
4xA15 guest w/o patch: 80.212s
8xA15 guest w/o patch: Could not be bothered to find out

2xA15 guest w/ patch: 2.102s
4xA15 guest w/ patch: 3.205s
8xA15 guest w/ patch: 6.887s

So we go from a 40x degradation to 1.5x in the 2x overcommit case,
which is vaguely more acceptable.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
arch/arm/include/asm/kvm_arm.h
arch/arm/kvm/Kconfig
arch/arm/kvm/handle_exit.c