From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH][RFC] Improve PIO latency Date: Tue, 06 Feb 2007 08:35:53 -0600 Message-ID: <45C89249.6030000@cs.utexas.edu> References: <45C56188.2050408@cs.utexas.edu> <45C85C6D.5030501@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Avi Kivity Return-path: In-Reply-To: <45C85C6D.5030501-atKUWr5tajBWk0Htik3J/w@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 Avi Kivity wrote: > Anthony Liguori wrote: >> The attached patch modifies libkvmctl to only make SET_REG/GET_REG >> ioctls when needed for PIO instructions. I was only able to do this >> for out instructions because I didn't want to break the kernel ABI. >> >> I think we should change the API though so we can do this with other >> types of IO instructions. Before this patch, the time line for a PIO >> instruction looks something like this: >> >> All times in nanoseconds and are round trips from the guests >> perspective for an out instruction on an AMD X2 4200. >> >> 1015 - immediately after restoring saving guest registers >> 1991 - handled within the kernel in io_interception >> 2294 - libkvmctl returns immediately >> 2437 - w/ patch >> 3311 - w/o patch >> >> The first data point is the best we could possible do. The only work >> being done after the VMRUN is a VMSAVE/VMLOAD, saving the guest >> registers, and restoring the host registers. The VMSAVE/VMLOAD is >> needed so that vmcb->save.eip can be updated.[1] I played around >> reducing the register savings but the differences weren't noticable. >> >> I suspect that more intelligent handling of things like FPU >> save/restore should be able to reduce the second data point. This >> will also improve some other exit paths (like shadow paging). We >> save/restore an awful lot of state considering that we probably >> return back to the guest for the vast majority of exits. >> > > These are very encouraging numbers. I'd expected the vmexit to be > more expensive, and fpu save/restore to be less expensive. Since, as > you say, we can eliminate the fpu save/restore in many cases, we have > a net win :) > > The planned userspace api changes will eliminate registers and virtual > addresses for pio. This will both improve performance and make the > api more architecture agnostic. Cool! > I'm applying the patch now, even though it will be obsoleted soon, as > it's always nice to have a performance improvement. > > > ps. that [1] is a dangling reference? Sorry, it was supposed to be something like: [1] I have no idea why there is are VM{SAVE,LOAD} instructions in the first place. AFAIK, there is nothing useful you can do after a VMRUN without doing a VMSAVE since you cannot re-enter the VM without updating the VMCB. Regards, Anthony Liguori ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642