Please sign in to comment.
MFV r323535: 8585 improve batching done in zil_commit()
FreeBSD notes: - this MFV reverts FreeBSD commit r314549 to make the merge easier - at present our emulation of cv_timedwait_hires is rather poor, so I elected to use cv_timedwait_sbt directly Please see the differential revision for details. Unfortunately, I did not get any positive reviews, so there could be bugs in the FreeBSD-specific piece of the merge. Hence, the long MFC timeout. illumos/illumos-gate@1271e4b illumos/illumos-gate@1271e4b 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 <email@example.com> Reviewed by: Matt Ahrens <firstname.lastname@example.org> Reviewed by: George Wilson <email@example.com> Approved by: Dan McDonald <firstname.lastname@example.org> Author: Prakash Surya <email@example.com> MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D12355
- Loading branch information...
Showing with 1,383 additions and 292 deletions.
- +8 −3 cddl/contrib/opensolaris/cmd/ztest/ztest.c
- +7 −0 sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c
- +1 −1 sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dmu.h
- +6 −2 sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil.h
- +61 −11 sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil_impl.h
- +1 −0 sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h
- +6 −6 sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c
- +7 −5 sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
- +1,248 −249 sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c
- +25 −8 sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c
- +9 −6 sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c
- +4 −1 sys/cddl/contrib/opensolaris/uts/common/sys/debug.h
Oops, something went wrong.