[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCHv5 06/10] migration: search for zero instead of d
From: |
Peter Lieven |
Subject: |
Re: [Qemu-devel] [PATCHv5 06/10] migration: search for zero instead of dup pages |
Date: |
Sat, 6 Apr 2013 00:06:01 +0200 |
Am 05.04.2013 um 22:00 schrieb Paolo Bonzini <address@hidden>:
> Il 05/04/2013 21:23, Kevin Wolf ha scritto:
>>>> virtually all dup pages are zero pages. remove
>>>> the special is_dup_page() function and use the
>>>> optimized buffer_find_nonzero_offset() function
>>>> instead.
>>>>
>>>> here buffer_find_nonzero_offset() is used directly
>>>> to avoid the unnecssary additional checks in
>>>> buffer_is_zero().
>>>>
>>>> raw performace gain checking 1 GByte zeroed memory
>>>> over is_dup_page() is approx. 10-12% with SSE2
>>>> and 8-10% with unsigned long arithmedtic.
>>>>
>>>> Signed-off-by: Peter Lieven <address@hidden>
>>>> Reviewed-by: Orit Wasserman <address@hidden>
>>>> Reviewed-by: Eric Blake <address@hidden>
>> Okay, so I bisected again and this is the second patch that is involved
>> in the slowness of qemu-iotests case 007.
>>
>> The problem seems to be that the RAM of a guest is in fact _not_ zeroed
>> during initialisation. It hits my test case reliably because I'm running
>> with MALLOC_PERTURB_. Now I'm wondering if in practice this happens only
>> under such test conditions, or if real guests could be affected as well
>> and we should make sure to get zeroed memory for RAM.
>
> I think we should MADV_DONTNEED it.
i have to correct myself, on Linux it seems that MADV_DONTNEED guarantees that
subsequent reads will return a zero filled page.
If I am right with that we could MADV_DONTNEED the memory on startup and keep
not sending zero pages in bulk stage if we are running under Linux. Am I right
with that?
Peter
Re: [Qemu-devel] [PATCHv5 06/10] migration: search for zero instead of dup pages, Peter Lieven, 2013/04/08