public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: OHMURA Kei <ohmura.kei@lab.ntt.co.jp>
To: kvm@vger.kernel.org, qemu-devel@nongnu.org
Cc: avi@redhat.com, Jan Kiszka <jan.kiszka@siemens.com>,
	anthony@codemonkey.ws, ohmura.kei@lab.ntt.co.jp
Subject: [PATCH 0/3] qemu-kvm: Check the dirty and non-dirty pages by multiple size
Date: Mon, 08 Feb 2010 19:22:10 +0900	[thread overview]
Message-ID: <4B6FE5D2.9090505@lab.ntt.co.jp> (raw)

The dirty and non-dirty pages are checked one by one in vl.c.
Since we believe that most of the memory is not dirty,
checking the dirty and non-dirty pages by multiple page size
should be much faster than checking them one by one.

We think there is mostly two kind of situation.
One is almost all the page is clean because there should be small
amount of pages become dirty between each round of dirty bitmap check.
The other is all the pages is dirty because all the bitmap is marked as
dirty at the beginning of migration.

To prove our prospect,
we have evaluated effect of this patch. we compared runtime of
ram_save_remaining with original ram_save_remaining() and
ram_save_remaining() using functions of this patch.

Test Environment:
CPU: 4x Intel Xeon Quad Core 2.66GHz
Mem size: 6GB
kvm version: 2.6.31-17-server
qemu version: commit ed880109f74f0a4dd5b7ec09e6a2d9ba4903d9a5

Host OS: Ubuntu 9.10 (kernel 2.6.31)
Guest OS: Debian/GNU Linux lenny (kernel 2.6.26)
Guest Mem size: 512MB

Conditions of experiments are as follows:
Cond1: Guest OS periodically makes the 256MB continuous dirty pages.
Cond2: Guest OS periodically makes the 256MB dirty pages and non-dirty pages
in turn.
Cond3: Guest OS read 3GB file, which is bigger than memory.
Cond4: Guest OS read/write 3GB file, which is bigger than memory.

Experimental results:
Cond1: 8~16 times speed up
Cond2: 3~4 times speed down
Cond3: 8~16 times speed up
Cond4: 2~16 times speed up

# Runtime of ram_save_remaining() is changed by the number of remaining
# dirty pages.




                 reply	other threads:[~2010-02-08 10:23 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=4B6FE5D2.9090505@lab.ntt.co.jp \
    --to=ohmura.kei@lab.ntt.co.jp \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --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