Ingo Molnar wrote: > * Avi Kivity <[EMAIL PROTECTED]> 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 _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
