From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: KVM performance Date: Sat, 27 Jan 2007 23:48:57 +1100 Message-ID: <1169902138.32208.25.camel@localhost.localdomain> References: <1169857267.30807.44.camel@localhost.localdomain> <45BB0E85.9060303@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, tim.c.chen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org To: Avi Kivity Return-path: In-Reply-To: <45BB0E85.9060303-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 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). > - 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? > - 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. > - better heuristics for recycling page tables are needed Definitely a whole area of research here... > - prefaulting for common access patterns can help Hmm, interesting idea. Any specific thoughts? > - 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 Cheers! Rusty. ------------------------------------------------------------------------- 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