[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: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCHv5 06/10] migration: search for zero instead of dup pages |
Date: |
Fri, 05 Apr 2013 22:00:07 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 |
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.
Paolo
Re: [Qemu-devel] [PATCHv5 06/10] migration: search for zero instead of dup pages, Peter Lieven, 2013/04/08