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 _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
