Re: Seeking a KVM benchmark

Paolo Bonzini
2014-11-10T10:03:42Z

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.

Paolo