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:
>
>   
>> 3. The most expensive vmx context switch involves cpu migration:
>>
>> cpu 0:  vmclear vm1 /* decache vmx context into memory */
>> cpu 1:  vmptrld vm1
>>            ... vm register access
>>            vmlaunch
>>     
>
> ah. And you optimize this away if previously-used-CPU == curr-CPU and 
> the vmx context loaded on this CPU is the same as we are trying to run 
> now, right?
>
>   

Yes.  If we changed cpu, we do a ipi vmclear and a vmptrld.  If we just 
changed vm, we only do a vmptrld.  If nothing changed, we do nothing.

>> The vmlaunch instruction, like vmresume, causes a VM entry, but is 
>> documented to be significantly more expensive.  It is required after a 
>> vmclear.
>>
>> Currently, the vmclear is performed by an ipi, because we can only 
>> detect migration after the fact.  However, if we enlist the migration 
>> threads, we can vmclear before the process has left the cpu.
>>     
>
> the most common type of migration isnt even in the migration threads but 
> in simple try_to_wake_up(). And that call often does not run on the CPU 
> that has the VMX state ...
>
> i see no easy solution here - this really parallels all the lazy-FPU 
> problems. Would it really be all that expensive to just save/load the 
> VMX state in switch_to()? 

The Intel documentation explicitly states that a vmlaunch (required 
after flushing the vmx state using a vmclear) is much more expensive 
than a vmresume.  I'd expect the difference to become more important if 
they cache multiple VMs on one core, which seems to be the point of all 
this complexity.

> As SVN has shown it, we can rely on VMX state 
> save/load to become faster in the future. So we definitely shouldnt 
> design for a small-scale overhead in first-generation silicon.
>   

In this case I think the documentation indicates their long term plans.  
However, the only real answer is to measure.

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