mirror of
https://github.com/torvalds/linux.git
synced 2024-11-14 16:12:02 +00:00
58d5ec8f8e
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> |
||
|---|---|---|
| .. | ||
| arm.c | ||
| coproc_a7.c | ||
| coproc_a15.c | ||
| coproc.c | ||
| coproc.h | ||
| emulate.c | ||
| guest.c | ||
| handle_exit.c | ||
| init.S | ||
| interrupts_head.S | ||
| interrupts.S | ||
| Kconfig | ||
| Makefile | ||
| mmio.c | ||
| mmu.c | ||
| perf.c | ||
| psci.c | ||
| reset.c | ||
| trace.h | ||