On Mon, Jun 10, 2013 at 12:14:20PM +0200, Peter Lieven wrote: > on incoming migration do not memset pages to zero if they already read as > zero. > this will allocate a new zero page and consume memory unnecessarily. even > if we madvise a MADV_DONTNEED later this will only deallocate the memory > asynchronously. > > Signed-off-by: Peter Lieven <p...@kamp.de> > --- > arch_init.c | 14 ++++++++------ > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/arch_init.c b/arch_init.c > index 08fccf6..cf4e1d5 100644 > --- a/arch_init.c > +++ b/arch_init.c > @@ -832,14 +832,16 @@ static int ram_load(QEMUFile *f, void *opaque, int > version_id) > } > > ch = qemu_get_byte(f); > - memset(host, ch, TARGET_PAGE_SIZE); > + if (ch != 0 || !is_zero_page(host)) { > + memset(host, ch, TARGET_PAGE_SIZE); > #ifndef _WIN32 > - if (ch == 0 && > - (!kvm_enabled() || kvm_has_sync_mmu()) && > - getpagesize() <= TARGET_PAGE_SIZE) { > - qemu_madvise(host, TARGET_PAGE_SIZE, QEMU_MADV_DONTNEED); > - } > + if (ch == 0 && > + (!kvm_enabled() || kvm_has_sync_mmu()) && > + getpagesize() <= TARGET_PAGE_SIZE) { > + qemu_madvise(host, TARGET_PAGE_SIZE, QEMU_MADV_DONTNEED); > + }
Reviewed-by: Michael Roth <mdr...@linux.vnet.ibm.com> Also CC'ing qemu-stable, but from what I gather this just mitigates the performance impact of 1/2 and isn't strictly necessary to fix migration? i.e. we can still do outgoing migration to 1.5.0 guests? > #endif > + } > } else if (flags & RAM_SAVE_FLAG_PAGE) { > void *host; > > -- > 1.7.9.5 > >