Re: KVM performance

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Rusty Russell wrote:
> On Sat, 2007-01-27 at 10:34 +0200, Avi Kivity wrote:
>   
>> In addition, quite a few performance optimizations are missing from kvm:
>>     
>
> Hi Avi!
>
> 	Just thought I'd share my experience with some of these optimizations
> in lguest.  I use virtbench (http://ozlabs.org/~rusty/virtbench) to try
> to measure optimization results; it still needs more tests (and an
> explicit kvm backend).
>   

A kvm backend would be appreciated.

>   
>> - after modifying a pte, kvm doesn't preload the modified pte into 
>> shadow, but instead lets the guest fault it in
>>     
>
> lguest doesn't either, but don't you still want the fault to update the
> host accessed bit?
>   

The story here is that the guest is handling a pagefault and writing the 
new guest pte.  kvm traps the write (guest pagetables are write 
protected), and has the option of updating the shadow pte to reflect the 
guest pte.

The clever guest kernel will set the accessed bit (and the dirty bit on 
writable ptes) to avoid an rmw cycle by the hardware pagetable walker.

[two instrumented runs later]

Both Linux and Windows seem to do this optimization.

>   
>> - disk access is blocking instead of non-blocking.  this will be fixed 
>> by merging qemu-cvs, which uses aio for disk access.
>>     
>
> Do you plan on multiple guest I/Os outstanding, too?  I would think that
> I/O scheduling in the guest could be more effective than I/O scheduling
> in the host if there is more than one guest sharing a host device.  It
> could potentially reduce guest<->host transitions too.
>   

qemu-cvs has scsi emulation IIRC, which allows multiple outstanding 
requests.  But the big improvement comes from allowing even one 
outstanding request (current kvm will block the cpu as soon as a disk 
request is issued).


>> - prefaulting for common access patterns can help
>>     
>
> Hmm, interesting idea.  Any specific thoughts?
>
>   

Linear :)

Also, if we see a lot of host faults in a pagetable, but no guest 
faults, we can assume that we're rebuilding a recycled shadow page, and 
fault the entire page in at once.

>> - kvm currently saves the entire fpu state on every exit, even if it has 
>> not been modified
>>     
>
> This was measurable for lguest, but our transition is slow so your %
> improvement might be greater.  With intelligent TS (2.13GHz Core Duo2):
>
>  Time for one context switch via pipe: 53514 nsec
>  Time for one Copy-on-Write fault: 14841 nsec
>  Time to exec client once: 1155102 nsec
>  Time for one fork/exit/wait: 764490 nsec
>  Time for two PTE updates: 23800 nsec
>
> Removing it and restoring FPU every time:
>
>  Time for one context switch via pipe: 56229 nsec
>  Time for one Copy-on-Write fault: 15989 nsec
>  Time to exec client once: 1243624 nsec
>  Time for one fork/exit/wait: 824647 nsec
>  Time for two PTE updates: 25056 nsec
>   

Good, I hope it's worthwhile for kvm too.



-- 
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