hammer2 - Add xxhash to H2 and throw in debug stuff for performance testing.
authorMatthew Dillon <dillon@apollo.backplane.com>
Wed, 8 Jun 2016 23:06:51 +0000 (16:06 -0700)
committerMatthew Dillon <dillon@apollo.backplane.com>
Wed, 8 Jun 2016 23:06:51 +0000 (16:06 -0700)
commit7d565a4f16015b664e90560061ad7574c3e68737
tree873aa46d49f02efae45484d7b9084a4e2cee86ad
parente7d75765a12690c7d3bbf05bc3680156bbf2e03c
hammer2 - Add xxhash to H2 and throw in debug stuff for performance testing.

* Add the xxhash.  This is a high-speed non-cryptographic hash code
  algorithm.  Sam pointed me at the site, the code is available on
  github and is BSD licensed:

      git://github.com/Cyan4973/xxHash.git

  This hash has good distribution and is very fast.

* Change HAMMER2 to default to using xxhash64 instead of iscsi_crc32().
  xxhash can process data at several GBytes/sec where as even the
  multi-table iscsi_crc32() can only do around 500 MBytes/sec, which
  is too slow for today's modern storage subsystems (NVME can nominally
  do 1.5-2.5 GBytes/sec, and high-end cards can do 5GBytes/sec).

* There are four major paths that eat tons of CPU in H2:

  - The XIO path does a ton of allocation/deallocation and synchronous
    messaging.  This has not yet been fixed.

  - The check code (when it was iscsi_crc32()) slowed everything down.
    This is fixed, the default check code is now xxhash64.

  - The check code was being called over and over again for the same cached
    buffer due to the hammer2_chain_t structure being thrown away.

    Currently a hack involving a mask stored in the underlying DIO is being
    used to indicate that the check code was previously valid.  This is
    strictly temporary.  The actual mask will have to be stored in the
    device buffer cache buffer and a second one in the chain structure.

    The chain structure must be made persistent as well (not yet done).

  - The DEDUP code was also calling iscsi_crc32() redundantly (at least for
    reads).

    The read path has been fixed.  The write path is doable but requires more
    coding (not yet fixed).

  - The logical file cluster_read() in the kernel was not doing any read-ahead
    due to H2 not implementing BMAP, creating long synchronous latencies.

    The kernel code for cluster_read() and cluster_readcb() has been fixed
    to do read-ahead whether a logical BMAP is implemented or not.  H2 will
    now pipeline reads.

Suggested-by: Samuel J. Greear <sjg@thesjg.com> (xxhash)
22 files changed:
sbin/hammer2/Makefile
sbin/hammer2/cmd_debug.c
sbin/hammer2/cmd_info.c
sbin/hammer2/cmd_setcheck.c
sbin/hammer2/hammer2.h
sbin/newfs_hammer2/Makefile
sbin/newfs_hammer2/newfs_hammer2.c
sys/vfs/hammer2/Makefile
sys/vfs/hammer2/hammer2.h
sys/vfs/hammer2/hammer2_chain.c
sys/vfs/hammer2/hammer2_disk.h
sys/vfs/hammer2/hammer2_flush.c
sys/vfs/hammer2/hammer2_inode.c
sys/vfs/hammer2/hammer2_io.c
sys/vfs/hammer2/hammer2_ioctl.c
sys/vfs/hammer2/hammer2_strategy.c
sys/vfs/hammer2/hammer2_thread.c
sys/vfs/hammer2/hammer2_vfsops.c
sys/vfs/hammer2/hammer2_vnops.c
sys/vfs/hammer2/hammer2_xxhash.h [new file with mode: 0644]
sys/vfs/hammer2/xxhash/xxhash.c [new file with mode: 0644]
sys/vfs/hammer2/xxhash/xxhash.h [new file with mode: 0644]