performance specs on VT-x vmenter/exit

performance specs on VT-x vmenter/exit

[Dan]

[-- Attachment #1.1: Type: text/plain, Size: 845 bytes --]

Greetings Honorable KVM Devs!

I am doing research on the performance characteristics of the Intel VMX
instructions, specifically with respect to KVM. I need to count the cycles
for a VMENTER and VMEXIT instruction under various conditions. (But getting
it to work at all would be cool :)

So the idea is to drop the cycle count in a register from the VMM, force a
VMENTER, drop the count in a different register, and force a VMEXIT. Then
get a last count and do appropriate adding/subtracting.
I'm working with a 2.6.22.6 vanilla kernel on an Core2Duo with KVM-54.

Questions:
 Is there a better way to get these numbers?
 If not, where in the KVM source should I aim to put these instructions
(file/line number/general area)?
 Any tips on forcing a vmexit out of the guest immediately after the count?

Thank you so much for your time.
  :dan

[-- Attachment #1.2: Type: text/html, Size: 946 bytes --]

[-- Attachment #2: Type: text/plain, Size: 309 bytes --]

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: performance specs on VT-x vmenter/exit

[Avi Kivity]

Dan wrote:
> Greetings Honorable KVM Devs!
>
> I am doing research on the performance characteristics of the Intel
> VMX instructions, specifically with respect to KVM. I need to count
> the cycles for a VMENTER and VMEXIT instruction under various
> conditions. (But getting it to work at all would be cool :)
>
> So the idea is to drop the cycle count in a register from the VMM,
> force a VMENTER, drop the count in a different register, and force a
> VMEXIT. Then get a last count and do appropriate adding/subtracting.
> I'm working with a 2.6.22.6 <http://2.6.22.6> vanilla kernel on an
> Core2Duo with KVM-54.
>
> Questions:
>  Is there a better way to get these numbers?
>  If not, where in the KVM source should I aim to put these
> instructions (file/line number/general area)?
>  Any tips on forcing a vmexit out of the guest immediately after the
> count?
>
> Thank you so much for your time.
>   :dan


Have a look at user/test/x86/vmexit.c, which does exactly that.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Re: performance specs on VT-x vmenter/exit

[Anthony Liguori]

Avi Kivity wrote:
> Dan wrote:
>   
>> Greetings Honorable KVM Devs!
>>
>> I am doing research on the performance characteristics of the Intel
>> VMX instructions, specifically with respect to KVM. I need to count
>> the cycles for a VMENTER and VMEXIT instruction under various
>> conditions. (But getting it to work at all would be cool :)
>>
>> So the idea is to drop the cycle count in a register from the VMM,
>> force a VMENTER, drop the count in a different register, and force a
>> VMEXIT. Then get a last count and do appropriate adding/subtracting.
>> I'm working with a 2.6.22.6 <http://2.6.22.6> vanilla kernel on an
>> Core2Duo with KVM-54.
>>
>> Questions:
>>  Is there a better way to get these numbers?
>>  If not, where in the KVM source should I aim to put these
>> instructions (file/line number/general area)?
>>  Any tips on forcing a vmexit out of the guest immediately after the
>> count?
>>
>> Thank you so much for your time.
>>   :dan
>>     
>
>
> Have a look at user/test/x86/vmexit.c, which does exactly that.
>
>   

That only gives you the combined count of a vmenter and vmexit.  If you 
want to measure the individual counts of a vmenter and a vmexit, the 
easiest thing to do is make sure the tsc_offset is always zero, and has 
the host and guest cooperate.  The host stashes away the tsc before 
entering the guest, the guest immediately would take the tsc and stash 
it in a register and then immediately enter generate an exit.  The host 
would then immediately take the tsc and stash it away.  You now have 
three readings and can use them to identify the cost of vmenter and vmexit.

Regards,

Anthony Liguori



-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Re: performance specs on VT-x vmenter/exit

[Avi Kivity]

Anthony Liguori wrote:
>>
>>
>> Have a look at user/test/x86/vmexit.c, which does exactly that.
>>
>>   
>
> That only gives you the combined count of a vmenter and vmexit.

Right; furthermore it measures kvm overhead and not just instruction 
latency.

-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Re: performance specs on VT-x vmenter/exit

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>>>
>>>
>>> Have a look at user/test/x86/vmexit.c, which does exactly that.
>>>
>>>   
>>
>> That only gives you the combined count of a vmenter and vmexit.
>
> Right; furthermore it measures kvm overhead and not just instruction 
> latency.

True.  Also, I don't know what Dan is looking to measure, but the cost 
of vmexits will varying depending on the reason for exit.  vmexit.c uses 
cpuid() which I suspect is slower than vmexit or pio but faster than 
pf.  It would be interesting to measure the individual exit reasons.

Regards,

Anthony Liguori



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: performance specs on VT-x vmenter/exit

[Dan]

[-- Attachment #1.1: Type: text/plain, Size: 1183 bytes --]

Thanks for the lightning-fast response, guys.

I'll play around with vmexit.c and let some of this sink in.
I was hoping to get a clean count of ticks/vm[enter/exit] without the kvm
latency, and I thought putting in into the code in the kvm code in the
kernel source would accomplish something like that.

Getting counts per exit reason would be really neat too.

Thanks again, I'm sure I'll come back with more precise questions later :D
  :dan



On Dec 6, 2007 2:56 PM, Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> wrote:

> Avi Kivity wrote:
> > Anthony Liguori wrote:
> >>>
> >>>
> >>> Have a look at user/test/x86/vmexit.c, which does exactly that.
> >>>
> >>>
> >>
> >> That only gives you the combined count of a vmenter and vmexit.
> >
> > Right; furthermore it measures kvm overhead and not just instruction
> > latency.
>
> True.  Also, I don't know what Dan is looking to measure, but the cost
> of vmexits will varying depending on the reason for exit.  vmexit.c uses
> cpuid() which I suspect is slower than vmexit or pio but faster than
> pf.  It would be interesting to measure the individual exit reasons.
>
> Regards,
>
> Anthony Liguori
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 1667 bytes --]

[-- Attachment #2: Type: text/plain, Size: 277 bytes --]

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel