From: Paolo Bonzini <pbonzini@redhat.com>
To: Liang Li <liang.z.li@intel.com>, qemu-devel@nongnu.org
Cc: amit.shah@redhat.com, zhang.zhanghailiang@huawei.com,
dgilbert@redhat.com, quintela@redhat.com
Subject: Re: [Qemu-devel] [PATCH] migration: not send zero page header in ram bulk stage
Date: Fri, 15 Jan 2016 12:39:11 +0100 [thread overview]
Message-ID: <5698DA5F.2040404@redhat.com> (raw)
In-Reply-To: <1452851297-11198-1-git-send-email-liang.z.li@intel.com>
On 15/01/2016 10:48, Liang Li wrote:
> Now that VM's RAM pages are initialized to zero, (VM's RAM is allcated
> with the mmap() and MAP_ANONYMOUS option, or mmap() without MAP_SHARED
> if hugetlbfs is used.) so there is no need to send the zero page header
> to destination.
>
> 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.li@intel.com>
This does not work. Depending on the board, some pages are written by
QEMU before the guest starts. If the guest rewrites them with zeroes,
this change breaks migration.
Paolo
> ---
> 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;
> }
>
>
next prev parent reply other threads:[~2016-01-15 11:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-15 9:48 [Qemu-devel] [PATCH] migration: not send zero page header in ram bulk stage Liang Li
2016-01-15 10:17 ` Hailiang Zhang
2016-01-15 10:24 ` Li, Liang Z
2016-01-18 9:01 ` Hailiang Zhang
2016-01-19 1:26 ` Li, Liang Z
2016-01-19 3:11 ` Hailiang Zhang
2016-01-19 3:17 ` Li, Liang Z
2016-01-20 9:55 ` Paolo Bonzini
2016-01-20 9:59 ` Li, Liang Z
2016-01-19 3:25 ` Hailiang Zhang
2016-01-19 3:36 ` Li, Liang Z
2016-01-15 11:39 ` Paolo Bonzini [this message]
2016-01-16 14:12 ` Li, Liang Z
2016-01-15 18:57 ` Dr. David Alan Gilbert
2016-01-16 14:25 ` Li, Liang Z
2016-01-18 9:33 ` Dr. David Alan Gilbert
2016-01-18 9:17 ` Hailiang Zhang
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=5698DA5F.2040404@redhat.com \
--to=pbonzini@redhat.com \
--cc=amit.shah@redhat.com \
--cc=dgilbert@redhat.com \
--cc=liang.z.li@intel.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=zhang.zhanghailiang@huawei.com \
/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).