Hi,
On 2016/1/15 18:24, Li, Liang Z wrote:
It seems that this patch is incorrect, if the no-zero pages are zeroed again
during !ram_bulk_stage, we didn't send the new zeroed page, there will be
an error.
If not in ram_bulk_stage, still send the header, could you explain why it's
wrong?
Liang
I have made a mistake, and yes, this patch can speed up the live migration time,
especially when there are many zero pages, it will be more obvious.
I like this idea. Did you test it with postcopy ? Does it break postcopy ?
Thanks,
zhanghailiang
For guest just uses a small portions of RAM, this change can avoid
allocating all the guest's RAM pages in the destination node after
live migration. Another benefit is destination QEMU can save lots of
CPU cycles for zero page checking.
Signed-off-by: Liang Li <liang.z...@intel.com>
---
migration/ram.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c index 4e606ab..c4821d1
100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -705,10 +705,12 @@ static int save_zero_page(QEMUFile *f,
RAMBlock
*block, ram_addr_t offset,
if (is_zero_range(p, TARGET_PAGE_SIZE)) {
acct_info.dup_pages++;
- *bytes_transferred += save_page_header(f, block,
- offset |
RAM_SAVE_FLAG_COMPRESS);
- qemu_put_byte(f, 0);
- *bytes_transferred += 1;
+ if (!ram_bulk_stage) {
+ *bytes_transferred += save_page_header(f, block, offset |
+ RAM_SAVE_FLAG_COMPRESS);
+ qemu_put_byte(f, 0);
+ *bytes_transferred += 1;
+ }
pages = 1;
}
.
