Patchwork [PATCHv5,06/10] migration: search for zero instead of dup pages

login
register
mail settings
Submitter Peter Lieven
Date April 8, 2013, 8:33 a.m.
Message ID <49B72003-C5C1-4109-806F-260F3522BD5B@kamp.de>
Download mbox | patch
Permalink /patch/234599/
State New
Headers show

Comments

Peter Lieven - April 8, 2013, 8:33 a.m.
Am 05.04.2013 um 21:23 schrieb Kevin Wolf <kwolf@redhat.com>:

> Am 26.03.2013 um 10:58 hat Peter Lieven geschrieben:
>> 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 <pl@kamp.de>
>> Reviewed-by: Orit Wasserman <owasserm@redhat.com>
>> Reviewed-by: Eric Blake <eblake@redhat.com>
> 
> Okay, so I bisected again and this is the second patch that is involved
> in the slowness of qemu-iotests case 007.
> 

Can you try if the following solves your issue:



BR,
Peter
Kevin Wolf - April 8, 2013, 8:49 a.m.
Am 08.04.2013 um 10:33 hat Peter Lieven geschrieben:
> 
> Am 05.04.2013 um 21:23 schrieb Kevin Wolf <kwolf@redhat.com>:
> 
> > Am 26.03.2013 um 10:58 hat Peter Lieven geschrieben:
> >> 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 <pl@kamp.de>
> >> Reviewed-by: Orit Wasserman <owasserm@redhat.com>
> >> Reviewed-by: Eric Blake <eblake@redhat.com>
> > 
> > Okay, so I bisected again and this is the second patch that is involved
> > in the slowness of qemu-iotests case 007.
> > 
> 
> Can you try if the following solves your issue:
> 
> diff --git a/exec.c b/exec.c
> index 786987a..54baa4a 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -1071,6 +1071,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
>              memory_try_enable_merging(new_block->host, size);
>          }
>      }
> +    qemu_madvise(new_block->host, size, QEMU_MADV_DONTNEED);
>      new_block->length = size;
>  
>      /* Keep the list sorted from biggest to smallest block.  */

It does. But perhaps Paolo's suggestion of using mmap() to allocate the
memory would be better. I'm not sure how MADV_DONTNEED behaves on
non-Linux.

Kevin
Peter Lieven - April 8, 2013, 8:50 a.m.
Am 08.04.2013 um 10:49 schrieb Kevin Wolf <kwolf@redhat.com>:

> Am 08.04.2013 um 10:33 hat Peter Lieven geschrieben:
>> 
>> Am 05.04.2013 um 21:23 schrieb Kevin Wolf <kwolf@redhat.com>:
>> 
>>> Am 26.03.2013 um 10:58 hat Peter Lieven geschrieben:
>>>> 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 <pl@kamp.de>
>>>> Reviewed-by: Orit Wasserman <owasserm@redhat.com>
>>>> Reviewed-by: Eric Blake <eblake@redhat.com>
>>> 
>>> Okay, so I bisected again and this is the second patch that is involved
>>> in the slowness of qemu-iotests case 007.
>>> 
>> 
>> Can you try if the following solves your issue:
>> 
>> diff --git a/exec.c b/exec.c
>> index 786987a..54baa4a 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -1071,6 +1071,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
>>             memory_try_enable_merging(new_block->host, size);
>>         }
>>     }
>> +    qemu_madvise(new_block->host, size, QEMU_MADV_DONTNEED);
>>     new_block->length = size;
>> 
>>     /* Keep the list sorted from biggest to smallest block.  */
> 
> It does. But perhaps Paolo's suggestion of using mmap() to allocate the
> memory would be better. I'm not sure how MADV_DONTNEED behaves on
> non-Linux.

its not guaranteed to zero memory.

Peter

> 
> Kevin

Patch

diff --git a/exec.c b/exec.c
index 786987a..54baa4a 100644
--- a/exec.c
+++ b/exec.c
@@ -1071,6 +1071,7 @@  ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
             memory_try_enable_merging(new_block->host, size);
         }
     }
+    qemu_madvise(new_block->host, size, QEMU_MADV_DONTNEED);
     new_block->length = size;
 
     /* Keep the list sorted from biggest to smallest block.  */