qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Shahar Livne <shahar@codefidence.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH] cut large snapshot startup time (Vista runs in 5 secs)
Date: Mon, 19 May 2008 13:18:59 +0300	[thread overview]
Message-ID: <48315413.9080005@codefidence.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]

This patch is a result of profiling research which I've done to shorten 
the startup time of a windows Vista snapshot on kvm, as part of 
http://support-matrix.com product.

The virtualization engine of SupportMatrix(tm) is based on kvm-35.
Background: The product starts for each network user (e.g. 30 users) a 
specific kvm/qemu snapshot based on details from the application 
database, and presents it on the user's browser using vnc java applet.

Everything played fine with less demanding guest OSs (like Windows XP / 
Windows 2000), but Vista which requires minimum 512MB took too long to 
start.
A customer's request to lower a the startup time of a vista snapshot 
from 10 seconds by at least 50% was the reason for the profiling effort.

It was found that loading the stored RAM within the qcow2 is responsible 
for a major part of the startup time. The function in vl.c, 
ram_load_static on snapshot loading (and ram_save_static on snapshot 
saving) run RAM/BDRV_HASH_BLOCK_SIZE times, which means that for 0.5GB 
RAM, and the default BDRV_HASH_BLOCK_SIZE=1k there are 500k calls of the 
ram_decompress_buf function (practically zlib decompression).
This is heavy, and it takes long time (around 9 seconds).
The patch uses a 16 times bigger buffer, and therefore reduces the 
amount of calls by 16 times (was found to be the best for my setup by 
trial and error). The time of the ram_load_static was reduced from 9 
seconds to around 4-5 seconds.
This change doesn't disturb also kvm (e.g. the video-addresses are still 
fully skipped within ram_load_static and ram_save_static).
Changing the compression (avoiding it or changing the default 
Z_DEFAULT_STRATEGY algorithm) did not improve the numbers.

Since I've seen that also in recent versions of qemu and kvm, the 
BDRV_HASH_BLOCK_SIZE is still 1k, I suggest the change. This change 
becomes more relevant when snapshots of guests with large amount of RAM 
are used.
I post it on qemu mailing list, since it is qemu issue and not kvm issue.

Details of the test setup:
Windows Vista was installed with 512MB.
Host OS is RedHat Enterprise 5.0
The server is Xeon E5310 1.60GHz, 8 cores, 16GB.
NO disk raids. Just simple IDE disk.
Final Vista snapshot startup time is around 5 seconds.

It is important to mention that old snapshots must be converted once 
this patch is applied.
Also, I would like to note that I've encountered no problems while 
working with the 16k based snapshots.
The patch was done against trunk r4497.

I'll be glad to get comments,
Shahar

[-- Attachment #2: snapshot_startup_time_cut.diff --]
[-- Type: text/x-patch, Size: 322 bytes --]

diff -Nuar qemu-4497/vl.c qemu-mod/vl.c
--- qemu-4497/vl.c	2008-05-19 12:26:46.000000000 +0300
+++ qemu-mod/vl.c	2008-05-19 12:30:51.000000000 +0300
@@ -6407,7 +6407,7 @@
     return 0;
 }
 
-#define BDRV_HASH_BLOCK_SIZE 1024
+#define BDRV_HASH_BLOCK_SIZE 16384
 #define IOBUF_SIZE 4096
 #define RAM_CBLOCK_MAGIC 0xfabe
 

             reply	other threads:[~2008-05-19 10:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-19 10:18 Shahar Livne [this message]
2008-06-02  1:59 ` [Qemu-devel] [PATCH] cut large snapshot startup time (Vista runs in 5 secs) andrzej zaborowski
2008-06-08  8:10   ` Shahar Livne

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=48315413.9080005@codefidence.com \
    --to=shahar@codefidence.com \
    --cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).