Re: [PATCH 0/8] KVM updates for 2.6.20-rc2

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Ingo Molnar wrote:
> * Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>
>   
>>> yeah. Would be nice to see some hard numbers about how many cycles all 
>>> these context load/save variants take.
>>>       
>> PIO latency on AMD (including a trip to qemu and back) is 5500 cycles 
>> [1].  Intel is significantly higher.
>>
>> [1] http://virt.kernelnewbies.org/KVM/Performance
>>     
>
> ok. We need the IPI only on VMX, right? 

Correct.

> That's because it has cached VM 
> state in the CPU that needs to be flushed out to the public VM area 
> before it can be loaded into another CPU, correct? 

Correct.

> Is there no cheap way 
> to do this flushing preemptively (say in vcpu_put()), to make the VM 
> context potentially loadable into another CPU?

You could issue a vmclear, but that forces a vm entry on the _same_ cpu 
to use vmlaunch instead of vmresume, which is documented as expensive. 
If we assume that cpu migrations are much rarer than vm entries (a very 
safe assumption), then the ipi is better than forcing a vmclear on 
vcpu_put().

Here's the relevant text from scripture:

The following software usage is consistent with these limitations:
• VMCLEAR should be executed for a VMCS before it is used for VM entry.
• VMLAUNCH should be used for the first VM entry using a VMCS after 
VMCLEAR has
been executed for that VMCS.
• VMRESUME should be used for any subsequent VM entry using a VMCS 
(until the next
execution of VMCLEAR for the VMCS).
It is expected that, in general, VMRESUME will have lower latency than 
VMLAUNCH. Since
“migrating” a VMCS from one logical processor to another requires use of 
VMCLEAR (see
Section 20.10.1), which sets the launch state of the VMCS to “clear,” 
such migration requires
the next VM entry to be performed using VMLAUNCH. Software developers 
can avoid the
performance cost of increased VM-entry latency by avoiding unnecessary 
migration of a VMCS
from one logical processor to another.



-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV