[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC migration of zero pages
From: |
Peter Lieven |
Subject: |
Re: [Qemu-devel] RFC migration of zero pages |
Date: |
Sun, 03 Feb 2013 08:24:40 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 |
Am 01.02.2013 18:03, schrieb Paolo Bonzini:
> Il 31/01/2013 09:33, Orit Wasserman ha scritto:
>>>> If my above assumption that the guest reads unmapped memory as zeroes is
>>>> right, this mapping
>>>> is not necessary in the case of a zero dup page.
>>>>
>>>> We just have to make sure that we are still in the very first round when
>>>> deciding not to sent
>>>> a zero page, because otherwise it could be a page that has become zero
>>>> during migration and
>>>> this of course has to be transferred.
>> OK, so if we won't send the pages than it won't be allocate in the dst and
>> it can improve both
>> memory usage and reduce cpu consumption on it.
>> That can be good for over commit scenario.
>
> We don't allocate zero pages in the destination:
>
> #ifndef _WIN32
> if (ch == 0 &&
> (!kvm_enabled() || kvm_has_sync_mmu()) &&
> getpagesize() <= TARGET_PAGE_SIZE) {
> qemu_madvise(host, TARGET_PAGE_SIZE, QEMU_MADV_DONTNEED);
> }
> #endif
Sorry I was not aware of this. So the only possible benefit left would be to
not sent zero pages in
the first round at all which would avoid the 9 bytes (header + ch) per page +
memset and madvise on the target.
Peter
>
> Paolo
>