From: Paolo Bonzini <pbonzini@redhat.com>
To: Gleb Natapov <gleb@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>, kvm list <kvm@vger.kernel.org>
Subject: Re: Seeking a KVM benchmark
Date: Tue, 11 Nov 2014 12:07:40 +0100 [thread overview]
Message-ID: <5461EDFC.1000803@redhat.com> (raw)
In-Reply-To: <5460AC7C.8040409@redhat.com>
On 10/11/2014 13:15, Paolo Bonzini wrote:
>
>
> On 10/11/2014 11:45, Gleb Natapov wrote:
>>> 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.
>
> Yes, definitely.
I've reproduced Andy's results on Ivy Bridge:
NX off ~6900 cycles (EFER)
NX on, SCE off ~14600 cycles (urn)
NX on, SCE on ~6900 cycles (same value)
I also asked Intel about clarifications.
On Core 2 Duo the results are weird. There is no LOAD_EFER control,
so Andy's patch does not apply and the only interesting paths are urn
and same value.
The pessimization of EFER writes does _seem_ to be there, since I can
profile for iTLB flushes (r4082 on this microarchitecture) and get:
0.14% qemu-kvm [kernel.kallsyms] [k] native_write_msr_safe
0.14% qemu-kvm [kernel.kallsyms] [k] native_flush_tlb
but these are the top two results and it is not clear to me why perf
only records them as "0.14%"... Also, this machine has no EPT, so virt
suffers a lot from TLB misses anyway.
Nevertheless I tried running kvm-unit-tests with different values of the
MSRs to see what's the behavior.
NX=1/SCE=0 NX=1/SCE=1 all MSRs equal
cpuid 3374 3448 3608
vmcall 3274 3337 3478
mov_from_cr8 11 11 11
mov_to_cr8 15 15 15
inl_from_pmtimer 17803 16346 15156
inl_from_qemu 17858 16375 15163
inl_from_kernel 6351 6492 6622
outl_to_kernel 3850 3900 4053
mov_dr 116 116 117
ple-round-robin 15 16 16
wr_tsc_adjust_msr 3334 3417 3570
rd_tsc_adjust_msr 3374 3404 3605
mmio-no-eventfd:pci-mem 19188 17866 16660
mmio-wildcard-eventfd:pci-mem 7319 7414 7595
mmio-datamatch-eventfd:pci-mem 7304 7470 7605
portio-no-eventfd:pci-io 13219 11780 10447
portio-wildcard-eventfd:pci-io 3951 4024 4149
portio-datamatch-eventfd:pci-io 3940 4026 4228
In the last column, all shared MSRs are equal (*) host and guest. The
difference is very noisy on newer processors, but quite visible on the
older processor. It is weird though that the light-weight exits become
_more_ expensive as more MSRs are equal between guest and host.
Anyhow, this is more of a curiosity since the proposed patch has no effect.
Next will come Nehalem. Nehalem has both LOAD_EFER and EPT, so it's
already a good target. I can test Westmere too, as soon as I find
someone that has it, but it shouldn't give surprises.
Paolo
(*) run this:
#! /usr/bin/env python
class msr(object):
def __init__(self):
try:
self.f = open('/dev/cpu/0/msr', 'r', 0)
except:
self.f = open('/dev/msr0', 'r', 0)
def read(self, index, default = None):
import struct
self.f.seek(index)
try:
return struct.unpack('Q', self.f.read(8))[0]
except:
return default
m = msr()
for i in [0xc0000080, 0xc0000081, 0xc0000082, 0xc0000083, 0xc0000084]:
print ("wrmsr(0x%x, 0x%x);" % (i, m.read(i)))
and add the result to the enable_nx function.
next prev parent reply other threads:[~2014-11-11 11:07 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
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 [this message]
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=5461EDFC.1000803@redhat.com \
--to=pbonzini@redhat.com \
--cc=gleb@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=luto@amacapital.net \
/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