| Message ID | 1363881457-14814-8-git-send-email-pl@kamp.de |
|---|---|
| State | New |
| Headers | show |
On 03/21/2013 09:57 AM, Peter Lieven wrote: > during bulk stage of ram migration if a page is a > zero page do not send it at all. > the memory at the destination reads as zero anyway. > > even if there is an madvise with QEMU_MADV_DONTNEED > at the target upon receipt of a zero page I have observed > that the target starts swapping if the memory is overcommitted. > it seems that the pages are dropped asynchronously. > > Signed-off-by: Peter Lieven <pl@kamp.de> > --- > arch_init.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > if (is_zero_page(p)) { > acct_info.dup_pages++; > - bytes_sent = save_block_hdr(f, block, offset, cont, > - RAM_SAVE_FLAG_COMPRESS); > - qemu_put_byte(f, *p); > - bytes_sent += 1; > + if (!ram_bulk_stage) { > + bytes_sent = save_block_hdr(f, block, offset, cont, > + RAM_SAVE_FLAG_COMPRESS); > + qemu_put_byte(f, 0); > + } > + bytes_sent++; Logic is STILL wrong. I pointed out in v2 that bytes_sent should not be incremented if you are not sending the page, so it needs to be inside the 'if (!ram_bulk_stage)'. Do we want to add a new migration statistic counter of how many zero pages we omitted sending during the bulk stage?
Am 21.03.2013 um 20:26 schrieb Eric Blake <eblake@redhat.com>: > On 03/21/2013 09:57 AM, Peter Lieven wrote: >> during bulk stage of ram migration if a page is a >> zero page do not send it at all. >> the memory at the destination reads as zero anyway. >> >> even if there is an madvise with QEMU_MADV_DONTNEED >> at the target upon receipt of a zero page I have observed >> that the target starts swapping if the memory is overcommitted. >> it seems that the pages are dropped asynchronously. >> >> Signed-off-by: Peter Lieven <pl@kamp.de> >> --- >> arch_init.c | 10 ++++++---- >> 1 file changed, 6 insertions(+), 4 deletions(-) > >> if (is_zero_page(p)) { >> acct_info.dup_pages++; >> - bytes_sent = save_block_hdr(f, block, offset, cont, >> - RAM_SAVE_FLAG_COMPRESS); >> - qemu_put_byte(f, *p); >> - bytes_sent += 1; >> + if (!ram_bulk_stage) { >> + bytes_sent = save_block_hdr(f, block, offset, cont, >> + RAM_SAVE_FLAG_COMPRESS); >> + qemu_put_byte(f, 0); >> + } >> + bytes_sent++; > > Logic is STILL wrong. I pointed out in v2 that bytes_sent should not be > incremented if you are not sending the page, so it needs to be inside > the 'if (!ram_bulk_stage)'. If its inside then bytes_sent will be -1 at the end if we skip a page. This would lead to the raw page being sent. This way it is 0 what I think is correct. > > Do we want to add a new migration statistic counter of how many zero > pages we omitted sending during the bulk stage? You mean sth like skipped zero pages? I was also thinking of renaming dup_pages into zero_pages in the statistics, but this could break someone relying on it so I left it as is. Peter > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org >
diff --git a/arch_init.c b/arch_init.c index 2b59454..c2cb40a 100644 --- a/arch_init.c +++ b/arch_init.c @@ -438,10 +438,12 @@ static int ram_save_block(QEMUFile *f, bool last_stage) bytes_sent = -1; if (is_zero_page(p)) { acct_info.dup_pages++; - bytes_sent = save_block_hdr(f, block, offset, cont, - RAM_SAVE_FLAG_COMPRESS); - qemu_put_byte(f, *p); - bytes_sent += 1; + if (!ram_bulk_stage) { + bytes_sent = save_block_hdr(f, block, offset, cont, + RAM_SAVE_FLAG_COMPRESS); + qemu_put_byte(f, 0); + } + bytes_sent++; } else if (migrate_use_xbzrle()) { current_addr = block->offset + offset; bytes_sent = save_xbzrle_page(f, p, current_addr, block,
during bulk stage of ram migration if a page is a zero page do not send it at all. the memory at the destination reads as zero anyway. even if there is an madvise with QEMU_MADV_DONTNEED at the target upon receipt of a zero page I have observed that the target starts swapping if the memory is overcommitted. it seems that the pages are dropped asynchronously. Signed-off-by: Peter Lieven <pl@kamp.de> --- arch_init.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)