qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] optimize is_dup_page for zero pages


From: Peter Lieven
Subject: Re: [Qemu-devel] [RFC] optimize is_dup_page for zero pages
Date: Tue, 12 Mar 2013 21:10:28 +0100

Am 12.03.2013 um 13:02 schrieb Paolo Bonzini <address@hidden>:

> Il 12/03/2013 12:51, Peter Lieven ha scritto:
>>>> buffer_is_zero is used in somewhat special cases (block
>>>> streaming/copy-on-read) where throughput doesn't really matter, unlike
>>>> is_dup_page/find_zero_bit which are used in migration.  But you can use
>>>> similar code for is_dup_page and buffer_is_zero.
>> ok, i will prepare a patch series for review. at the moment without touching
>> is_dup_page(). you can decide later if you use buffer_Is_zero to check
>> for zero pages later (maybe if the first x-bit are zero).
>> 
>> Two comments on changing is_dup_page() to is_zero_page():
>> a) Would it make sense to only check for zero pages in the first (bulk) 
>> round?
> 
> Interesting idea.  Benchmark it. :)

After thinking about Windows VMs where all freed memory is zeroed out I would
suggest the following:

a) drop is_dup_page() and use buffer_is_zero() with a small optimization that
buffer_is_zero() checks the first long being zero before unrolling up to 128 
bytes (with
the latest patches I have sent).
b) always check for zero pages, but do not send them in the bulk stage. even if
there is an madvise with QEMU_MADV_DONTNEED I have observed that the
target starts swapping if the memory is overcommitted. It seems that the pages 
are
dropped asynchronously. If they are not sent at all there is no issue. You can 
simply
test it by creating a VM with more memory than you physically have and migrate
it. While the source VM will not use a large resident size the target VM will 
use the
füll size at least temporary. 

> 
>> b) Would it make sense to not transfer zero pages at all in the first round?
> 
> Perhaps yes, but I'm not sure how to efficiently implement it.  There
> really isn't a well-specified first round in the RAM migration code.  Of
> course you could have another bitmap for known-zero pages.

please have a look at 

[PATCH 3/9] migration: add an indicator for bulk state of ram migration

Peter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]