Re: [PATCH][RFC] Improve PIO latency

[Anthony Liguori <aliguori-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.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