From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/8] KVM updates for 2.6.20-rc2 Date: Thu, 28 Dec 2006 16:18:43 +0200 Message-ID: <4593D243.1030301@qumranet.com> References: <45939755.7010603@qumranet.com> <20061228103345.GA4708@elte.hu> <4593A4B7.2070404@qumranet.com> <20061228113038.GA16190@elte.hu> <4593B948.5090009@qumranet.com> <20061228133746.GC3392@elte.hu> <4593CB61.5050709@qumranet.com> <20061228135020.GA7606@elte.hu> <4593CD74.6060202@qumranet.com> <20061228140742.GA10033@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Cc: kvm-devel Return-path: To: Ingo Molnar In-Reply-To: <20061228140742.GA10033-X9Un+BFzKDI@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Ingo Molnar wrote: > * Avi Kivity 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: =95 VMCLEAR should be executed for a VMCS before it is used for VM entry. =95 VMLAUNCH should be used for the first VM entry using a VMCS after = VMCLEAR has been executed for that VMCS. =95 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 =93migrating=94 a VMCS from one logical processor to another requires use o= f = VMCLEAR (see Section 20.10.1), which sets the launch state of the VMCS to =93clear,=94 = 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=3Djoin.php&p=3Dsourceforge&CID=3DDE= VDEV