]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
8585 improve batching done in zil_commit()
authorAndriy Gapon <avg@FreeBSD.org>
Wed, 13 Sep 2017 10:59:36 +0000 (10:59 +0000)
committerAndriy Gapon <avg@FreeBSD.org>
Wed, 13 Sep 2017 10:59:36 +0000 (10:59 +0000)
commitf3dbcb8c81432ef26a56091b9ec040a1ab017443
tree1a084f5940b87f61da9c9297868a9a87d672328a
parentf8453396dcc44b96806aeb697b91a4539850a3ce
8585 improve batching done in zil_commit()

illumos/illumos-gate@1271e4b10dfaaed576c08a812f466f6e81370e5e
https://github.com/illumos/illumos-gate/commit/1271e4b10dfaaed576c08a812f466f6e81370e5e

https://www.illumos.org/issues/8585
  The current implementation of zil_commit() can introduce significant
  latency, beyond what is inherent due to the latency of the underlying
  storage. The additional latency comes from two main problems:
  1. When there's outstanding ZIL blocks being written (i.e. there's
      already a "writer thread" in progress), then any new calls to
      zil_commit() will block waiting for the currently oustanding ZIL
      blocks to complete. The blocks written for each "writer thread" is
      coined a "batch", and there can only ever be a single "batch" being
      written at a time. When a batch is being written, any new ZIL
      transactions will have to wait for the next batch to be written,
      which won't occur until the current batch finishes.
  As a result, the underlying storage may not be used as efficiently
      as possible. While "new" threads enter zil_commit() and are blocked
      waiting for the next batch, it's possible that the underlying
      storage isn't fully utilized by the current batch of ZIL blocks. In
      that case, it'd be better to allow these new threads to generate
      (and issue) a new ZIL block, such that it could be serviced by the
      underlying storage concurrently with the other ZIL blocks that are
      being serviced.
  2. Any call to zil_commit() must wait for all ZIL blocks in its "batch"
      to complete, prior to zil_commit() returning. The size of any given
      batch is proportional to the number of ZIL transaction in the queue
      at the time that the batch starts processing the queue; which
      doesn't occur until the previous batch completes. Thus, if there's a
      lot of transactions in the queue, the batch could be composed of
      many ZIL blocks, and each call to zil_commit() will have to wait for
      all of these writes to complete (even if the thread calling
      zil_commit() only cared about one of the transactions in the batch).

Reviewed by: Brad Lewis <brad.lewis@delphix.com>
Reviewed by: Matt Ahrens <mahrens@delphix.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Approved by: Dan McDonald <danmcd@joyent.com>
Author: Prakash Surya <prakash.surya@delphix.com>
12 files changed:
cmd/ztest/ztest.c
uts/common/fs/zfs/dmu.c
uts/common/fs/zfs/sys/dmu.h
uts/common/fs/zfs/sys/zil.h
uts/common/fs/zfs/sys/zil_impl.h
uts/common/fs/zfs/sys/zio.h
uts/common/fs/zfs/txg.c
uts/common/fs/zfs/zfs_vnops.c
uts/common/fs/zfs/zil.c
uts/common/fs/zfs/zio.c
uts/common/fs/zfs/zvol.c
uts/common/sys/debug.h