Am 05.04.2013 um 22:00 schrieb Paolo Bonzini <pbonz...@redhat.com>: > 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 <p...@kamp.de> >>>> Reviewed-by: Orit Wasserman <owass...@redhat.com> >>>> Reviewed-by: Eric Blake <ebl...@redhat.com> >> 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
