public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>, kvm list <kvm@vger.kernel.org>
Subject: Re: Seeking a KVM benchmark
Date: Mon, 10 Nov 2014 12:45:31 +0200	[thread overview]
Message-ID: <20141110104531.GB26187@minantech.com> (raw)
In-Reply-To: <54608D77.2090907@redhat.com>

On Mon, Nov 10, 2014 at 11:03:35AM +0100, Paolo Bonzini wrote:
> 
> 
> On 09/11/2014 17:36, Andy Lutomirski wrote:
> >> The purpose of vmexit test is to show us various overheads, so why not
> >> measure EFER switch overhead by having two tests one with equal EFER
> >> another with different EFER, instead of hiding it.
> > 
> > I'll try this.  We might need three tests, though: NX different, NX
> > same but SCE different, and all flags the same.
> 
> The test actually explicitly enables NX in order to put itself in the 
> "common case":
> 
> commit 82d4ccb9daf67885a0316b1d763ce5ace57cff36
> Author: Marcelo Tosatti <mtosatti@redhat.com>
> Date:   Tue Jun 8 15:33:29 2010 -0300
> 
>     test: vmexit: enable NX
>     
>     Enable NX to disable MSR autoload/save. This is the common case anyway.
>     
>     Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>     Signed-off-by: Avi Kivity <avi@redhat.com>
> 
> (this commit is in qemu-kvm.git), so I guess forgetting to set SCE is
> just a bug.  The results on my Xeon Sandy Bridge are very interesting:
> 
> NX different            ~11.5k (load/save EFER path)
> NX same, SCE different  ~19.5k (urn path)
> all flags the same      ~10.2k
> 
> The inl_from_kernel results have absolutely no change, usually at most 5
> cycles difference.  This could be because I've added the SCE=1 variant
> directly to vmexit.c, so I'm running the tests one next to the other.
> 
> I tried making also the other shared MSRs the same between guest and
> host (STAR, LSTAR, CSTAR, SYSCALL_MASK), so that the user return notifier
> has nothing to do.  That saves about 4-500 cycles on inl_from_qemu.  I
> do want to dig out my old Core 2 and see how the new test fares, but it
> really looks like your patch will be in 3.19.
>
Please test on wide variety of HW before final decision. Also it would
be nice to ask Intel what is expected overhead. It is awesome if they
mange to add EFER switching with non measurable overhead, but also hard
to believe :) Also Andy had an idea do disable switching in case host
and guest EFERs are the same but IIRC his patch does not include it yet.

--
			Gleb.

  reply	other threads:[~2014-11-10 10:45 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-07  6:27 Seeking a KVM benchmark Andy Lutomirski
2014-11-07  7:17 ` Paolo Bonzini
2014-11-07 17:59   ` Andy Lutomirski
2014-11-07 18:11     ` Andy Lutomirski
2014-11-08 12:01     ` Gleb Natapov
2014-11-08 16:00       ` Andy Lutomirski
2014-11-08 16:44         ` Andy Lutomirski
2014-11-09  8:52           ` Gleb Natapov
2014-11-09 16:36             ` Andy Lutomirski
2014-11-10 10:03               ` Paolo Bonzini
2014-11-10 10:45                 ` Gleb Natapov [this message]
2014-11-10 12:15                   ` Paolo Bonzini
2014-11-10 14:23                     ` Avi Kivity
2014-11-10 17:28                       ` Paolo Bonzini
2014-11-10 17:38                         ` Gleb Natapov
2014-11-12 11:33                           ` Paolo Bonzini
2014-11-12 15:22                             ` Gleb Natapov
2014-11-12 15:26                               ` Paolo Bonzini
2014-11-12 15:32                                 ` Gleb Natapov
2014-11-12 15:51                                   ` Paolo Bonzini
2014-11-12 16:07                                     ` Andy Lutomirski
2014-11-12 17:56                                       ` Paolo Bonzini
2014-11-17 11:17                         ` Wanpeng Li
2014-11-17 11:18                           ` Paolo Bonzini
2014-11-17 12:00                             ` Wanpeng Li
2014-11-17 12:04                               ` Paolo Bonzini
2014-11-17 12:14                                 ` Wanpeng Li
2014-11-17 12:22                                   ` Paolo Bonzini
2014-11-11 11:07                     ` Paolo Bonzini
2014-11-10 19:17                   ` Andy Lutomirski

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=20141110104531.GB26187@minantech.com \
    --to=gleb@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=pbonzini@redhat.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