All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
To: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	tim.c.chen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
Subject: Re: KVM performance
Date: Sat, 27 Jan 2007 23:48:57 +1100	[thread overview]
Message-ID: <1169902138.32208.25.camel@localhost.localdomain> (raw)
In-Reply-To: <45BB0E85.9060303-atKUWr5tajBWk0Htik3J/w@public.gmane.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

  parent reply	other threads:[~2007-01-27 12:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-27  0:21 KVM performance Tim Chen
     [not found] ` <1169857267.30807.44.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2007-01-27  3:11   ` Fabian Deutsch
2007-01-27  8:34   ` Avi Kivity
     [not found]     ` <45BB0E85.9060303-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-01-27 12:48       ` Rusty Russell [this message]
     [not found]         ` <1169902138.32208.25.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2007-01-28  9:40           ` Avi Kivity
     [not found]             ` <45BC6F98.908-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-01-30 12:52               ` Rusty Russell
     [not found]                 ` <1170161536.17669.10.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2007-01-30 12:56                   ` Avi Kivity
     [not found]                     ` <45BF4082.3010803-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-01-31  1:54                       ` Rusty Russell
2007-01-30 15:11                   ` Anthony Liguori
  -- strict thread matches above, loose matches on Subject: below --
2008-11-14 18:35 Randy Broman
2008-11-14 18:58 ` David S. Ahern
2008-11-16 14:26 ` Avi Kivity
2008-11-16 22:08   ` Randy Broman
2008-11-17 14:50     ` Brian Jackson
2008-11-20 11:08     ` Avi Kivity
2009-04-03 11:32 BRAUN, Stefanie
2009-04-06 11:45 ` Avi Kivity
2009-04-06 12:13 ` Hauke Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1169902138.32208.25.camel@localhost.localdomain \
    --to=rusty-8n+1lvoiyb80n/f98k4iww@public.gmane.org \
    --cc=avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=tim.c.chen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.