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

[Peter Lieven]

Am 12.03.2013 um 12:46 schrieb Paolo Bonzini <address@hidden>:

> Il 12/03/2013 12:20, Peter Lieven ha scritto:
>>> * zero pages remain zero, and thus are only processed once
>> 
>> you are right this will be the case.
>> 
>>> 
>>> * non-zero pages are modified often, and thus are processed multiple times.
>>> 
>>> Your patch adds overhead in the case where a page is non-zero, which
>>> will be the common case in any non-artificial benchmark.  It _is_
>>> possible that the net result is positive because you warm the cache with
>>> the first 128 bytes of the page.  But without more benchmarking, it is
>>> reasonable to optimize is_dup_page for the case where the for loop rolls
>>> very few times.
>> 
>> Ok, good point. However, it will only enter the zero check if the first byte 
>> (or maybe could change
>> this to first 32 or 64 bit) is zero.
> 
> On big-endian architectures, I expect that the first byte will be zero
> very often.  (32- or 64-bit, much less indeed).
> 
>> What about using this patch for buffer_is_zero optimization?
> 
> 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?
b) Would it make sense to not transfer zero pages at all in the first round?
The memory at the target should read as zero (not allocated) anyway.

Peter