From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/2] ARM: KVM: Yield CPU when vcpu executes a WFE
Date: Tue, 15 Oct 2013 18:14:17 -0700 [thread overview]
Message-ID: <20131016011417.GA24837@cbox> (raw)
In-Reply-To: <1381253894-18114-2-git-send-email-marc.zyngier@arm.com>
On Tue, Oct 08, 2013 at 06:38:13PM +0100, Marc Zyngier wrote:
> 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.
>
Patch looks good, I can just apply it and add the other one I just send
as a reply if there are no objections.
Sorry for the long turn-around on this one.
-Christoffer
WARNING: multiple messages have this Message-ID (diff)
From: Christoffer Dall <christoffer.dall@linaro.org>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
raghavendra.kt@linux.vnet.ibm.com
Subject: Re: [PATCH v2 1/2] ARM: KVM: Yield CPU when vcpu executes a WFE
Date: Tue, 15 Oct 2013 18:14:17 -0700 [thread overview]
Message-ID: <20131016011417.GA24837@cbox> (raw)
In-Reply-To: <1381253894-18114-2-git-send-email-marc.zyngier@arm.com>
On Tue, Oct 08, 2013 at 06:38:13PM +0100, Marc Zyngier wrote:
> 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.
>
Patch looks good, I can just apply it and add the other one I just send
as a reply if there are no objections.
Sorry for the long turn-around on this one.
-Christoffer
next prev parent reply other threads:[~2013-10-16 1:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-08 17:38 [PATCH v2 0/2] KVM: Yield CPU when vcpu executes a WFE Marc Zyngier
2013-10-08 17:38 ` Marc Zyngier
2013-10-08 17:38 ` [PATCH v2 1/2] ARM: " Marc Zyngier
2013-10-08 17:38 ` Marc Zyngier
2013-10-16 1:13 ` [PATCH] KVM: ARM: Update comments for kvm_handle_wfi Christoffer Dall
2013-10-16 4:19 ` Bhushan Bharat-R65777
2013-10-16 4:37 ` Christoffer Dall
2013-10-16 1:14 ` Christoffer Dall [this message]
2013-10-16 1:14 ` [PATCH v2 1/2] ARM: KVM: Yield CPU when vcpu executes a WFE Christoffer Dall
2013-10-16 7:08 ` Marc Zyngier
2013-10-16 7:08 ` Marc Zyngier
2013-10-16 16:55 ` Christoffer Dall
2013-10-16 16:55 ` Christoffer Dall
2013-10-08 17:38 ` [PATCH v2 2/2] arm64: " Marc Zyngier
2013-10-08 17:38 ` Marc Zyngier
2013-10-16 1:14 ` Christoffer Dall
2013-10-16 1:14 ` Christoffer Dall
2013-10-09 9:12 ` [PATCH v2 0/2] " Raghavendra K T
2013-10-09 9:12 ` Raghavendra K T
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=20131016011417.GA24837@cbox \
--to=christoffer.dall@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.