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 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.