[Bug libc/19920] New: RFE: test whether a block of memory is all 0

["dgilbert at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19920

            Bug ID: 19920
           Summary: RFE: test whether a block of memory is all 0
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: dgilbert at redhat dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Hi,
  I'd like to suggest glibc adds a function to test a block of memory for being
all-0.

  My experience with this comes from QEMU's migration code, which has a
bandwidth saving optimisation which transmits memory pages (typically 4K) that
are all 0 with a special tag rather than transmitting 4K of zeros.  The time to
read the memory and check it is large enough that people have started writing
architecture specific CPU optimisations (there's currently an AVX2 version in
tree, and someone has just posted an ARM Neon implementation).

  It feels to me that this optimisation is more generally useful and therefore
should be in glibc; it's been suggested that 'dd' and 'cp' could benefit but I
expect there are other users as well.

  The current qemu implementation is:
    size_t buffer_find_nonzero_offset(const void *buf, size_t len)

    that returns an index to the first !0 byte; however all of our current uses
are just for testing whether the whole buffer is zero.

  The only suggestion for using libc at the moment is to memcmp() against a
zero filled buffer.

  One consideration to note in benchmarks is whether the common case is that
the block is all zero, or the common case is that a byte early in the blcok is
non-zero.

The current qemu implementation is around here:
   
http://git.qemu.org/?p=qemu.git;a=blob;f=util/cutils.c;h=43d1afbbecb599b3f8112aa7a32f2ccc365db0d6;hb=HEAD#l271

Dave

-- 
You are receiving this mail because:
You are on the CC list for the bug.