logo       

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

emulators.kvm.devel

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

Ingo Molnar wrote:
> * Avi Kivity <avi@xxxxxxxxxxxx> 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


<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise