From: Peter Lieven <pl@kamp.de>
To: qemu-devel@nongnu.org
Cc: kwolf@redhat.com, pbonzini@redhat.com, Peter Lieven <pl@kamp.de>
Subject: [Qemu-devel] [PATCHv3 0/9] buffer_is_zero / migration optimizations
Date: Thu, 21 Mar 2013 16:57:28 +0100 [thread overview]
Message-ID: <1363881457-14814-1-git-send-email-pl@kamp.de> (raw)
this is v3 of my patch series with various optimizations in
zero buffer checking and migration tweaks.
thanks especially to Eric Blake for reviewing.
v3:
- remove asserts, inline functions and add a check
function if buffer_find_nonzero_offset() can be used.
- use above check function in buffer_is_zero() and
find_next_bit().
- use buffer_is_nonzero_offset() directly to find
zero pages. we know that all requirements are met
for memory pages.
- fix C89 violation in buffer_is_zero().
- avoid derefencing p in ram_save_block() if we already
know the page is zero.
- fix initialization of last_offset in reset_ram_globals().
- avoid skipping pages with offset == 0 in bulk stage in
migration_bitmap_find_and_reset_dirty().
- compared to v1 check for zero pages also after bulk
ram migration as there are guests (e.g. Windows) which
zero out large amount of memory while running.
v2:
- fix description, add trivial zero check and add asserts
to buffer_find_nonzero_offset.
- add a constant for the unroll factor of buffer_find_nonzero_offset
- replace is_dup_page() by buffer_is_zero()
- added test results to xbzrle patch
- optimize descriptions
Peter Lieven (9):
move vector definitions to qemu-common.h
cutils: add a function to find non-zero content in a buffer
buffer_is_zero: use vector optimizations if possible
bitops: use vector algorithm to optimize find_next_bit()
migration: search for zero instead of dup pages
migration: add an indicator for bulk state of ram migration
migration: do not sent zero pages in bulk stage
migration: do not search dirty pages in bulk stage
migration: use XBZRLE only after bulk stage
arch_init.c | 62 ++++++++++++++++++-------------------------------
include/qemu-common.h | 27 +++++++++++++++++++++
util/bitops.c | 22 +++++++++++++++---
util/cutils.c | 55 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 123 insertions(+), 43 deletions(-)
--
1.7.9.5
next reply other threads:[~2013-03-21 15:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-21 15:57 Peter Lieven [this message]
2013-03-21 15:57 ` [Qemu-devel] [PATCHv3 1/9] move vector definitions to qemu-common.h Peter Lieven
2013-03-21 17:29 ` Eric Blake
2013-03-21 15:57 ` [Qemu-devel] [PATCHv3 2/9] cutils: add a function to find non-zero content in a buffer Peter Lieven
2013-03-21 18:12 ` Eric Blake
2013-03-21 19:11 ` Peter Lieven
2013-03-21 15:57 ` [Qemu-devel] [PATCHv3 3/9] buffer_is_zero: use vector optimizations if possible Peter Lieven
2013-03-21 18:16 ` Eric Blake
2013-03-21 15:57 ` [Qemu-devel] [PATCHv3 4/9] bitops: use vector algorithm to optimize find_next_bit() Peter Lieven
2013-03-21 19:18 ` Eric Blake
2013-03-21 15:57 ` [Qemu-devel] [PATCHv3 5/9] migration: search for zero instead of dup pages Peter Lieven
2013-03-21 19:24 ` Eric Blake
2013-03-21 15:57 ` [Qemu-devel] [PATCHv3 6/9] migration: add an indicator for bulk state of ram migration Peter Lieven
2013-03-21 19:27 ` Eric Blake
2013-03-21 15:57 ` [Qemu-devel] [PATCHv3 7/9] migration: do not sent zero pages in bulk stage Peter Lieven
2013-03-21 19:26 ` Eric Blake
2013-03-21 19:44 ` Peter Lieven
2013-03-21 15:57 ` [Qemu-devel] [PATCHv3 8/9] migration: do not search dirty " Peter Lieven
2013-03-21 19:27 ` Eric Blake
2013-03-21 19:57 ` Peter Lieven
2013-03-21 15:57 ` [Qemu-devel] [PATCHv3 9/9] migration: use XBZRLE only after " Peter Lieven
2013-03-21 19:31 ` Eric Blake
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=1363881457-14814-1-git-send-email-pl@kamp.de \
--to=pl@kamp.de \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.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 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.