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
next prev 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.