From: Paolo Bonzini <pbonzini@redhat.com>
To: "Li, Bin (Bin)" <bin.bl.li@alcatel-lucent.com>, kvm@vger.kernel.org
Cc: Neel Jatania <neel.jatania@alcatel-lucent.com>,
linux-kernel@vger.kernel.org, Avi Kiviti <avi@redhat.com>,
Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Mike Galbraith <efault@gmx.de>,
Chris Wright <chrisw@sous-sol.org>,
ttracy@redhat.com, "Nakajima, Jun" <jun.nakajima@intel.com>,
riel@redhat.com
Subject: Re: Enhancement for PLE handler in KVM
Date: Mon, 03 Mar 2014 20:20:59 +0100 [thread overview]
Message-ID: <5314D61B.9050407@redhat.com> (raw)
In-Reply-To: <5314C8C3.3090607@alcatel-lucent.com>
Il 03/03/2014 19:24, Li, Bin (Bin) ha scritto:
> Hello, all.
>
> The PLE handler attempts to determine an alternate vCPU to schedule. In
> some cases the wrong vCPU is scheduled and performance suffers.
>
> This patch allows for the guest OS to signal, using a hypercall, that
> it's starting/ending a critical section. Using this information in the
> PLE handler allows for a more intelligent VCPU scheduling determination
> to be made. The patch only changes the PLE behaviour if this new
> hypercall mechanism is used; if it isn't used, then the existing PLE
> algorithm continues to be used to determine the next vCPU.
>
> Benefit from the patch:
> - the guest OS real time performance being significantly improved when
> using hyper call marking entering and leaving guest OS kernel state.
> - The guest OS system clock jitter measured on on Intel E5 2620 reduced
> from 400ms down to 6ms.
> - The guest OS system lock is set to a 2ms clock interrupt. The jitter
> is measured by the difference between dtsc() value in clock interrupt
> handler and the expectation of tsc value.
> - detail of test report is attached as reference.
This patch doesn't include the corresponding guest changes, so it's not
clear how you would use it and what the overhead would be: a hypercall
is ~30 times slower than an uncontended spin_lock or spin_unlock.
In fact, performance numbers for common workloads are useful too.
Have you looked at the recent "paravirtual ticketlock"? It does roughly
the opposite as this patch: the guest can signal when it's been spinning
too much, and the host will schedule it out (which hopefully accelerates
the end of the critical section).
Paolo
> Path details:
>
> From 77edfa193a4e29ab357ec3b1e097f8469d418507 Mon Sep 17 00:00:00 2001
next prev parent reply other threads:[~2014-03-03 19:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <53061044.2000009@alcatel-lucent.com>
[not found] ` <530B9637.6030708@alcatel-lucent.com>
2014-03-03 18:24 ` Enhancement for PLE handler in KVM Li, Bin (Bin)
2014-03-03 19:20 ` Paolo Bonzini [this message]
2014-03-05 14:17 ` Li, Bin (Bin)
2014-03-05 14:49 ` Paolo Bonzini
2014-03-05 21:16 ` Li, Bin (Bin)
2014-03-07 3:06 ` Marcelo Tosatti
2014-03-07 14:26 ` Li, Bin (Bin)
2014-03-07 17:41 ` Marcelo Tosatti
2014-03-07 22:08 ` Li, Bin (Bin)
2014-03-08 1:54 ` Marcelo Tosatti
[not found] ` <531F19D7.6030909@alcatel-lucent.com>
2014-03-11 16:14 ` Paolo Bonzini
2014-03-12 13:05 ` Li, Bin (Bin)
2014-03-24 14:12 Raghavendra KT
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=5314D61B.9050407@redhat.com \
--to=pbonzini@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=avi@redhat.com \
--cc=bin.bl.li@alcatel-lucent.com \
--cc=chrisw@sous-sol.org \
--cc=efault@gmx.de \
--cc=jun.nakajima@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neel.jatania@alcatel-lucent.com \
--cc=riel@redhat.com \
--cc=ttracy@redhat.com \
--cc=vatsa@linux.vnet.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).