src-test2/sys/cddl/compat, branch releng/11.2

MFC r329759:

2018-04-16T03:38:37Z

9018 Replace kmem_cache_reap_now() with kmem_cache_reap_soon() illumos/illumos-gate@36a64e62848b51ac5a9a5216e894ec723cfef14e To prevent kmem_cache reaping from blocking other system resources, turn kmem_cache_reap_now() (which blocks) into kmem_cache_reap_soon(). Callers to kmem_cache_reap_soon() should use kmem_cache_reap_active(), which exploits #9017's new taskq_empty(). Reviewed by: Bryan Cantrill Reviewed by: Dan McDonald Reviewed by: Matthew Ahrens Reviewed by: Yuri Pankov Author: Tim Kordas FreeBSD does not use taskqueue for kmem caches reaping, so this change is less dramatic then it is on Illumos, just limiting reaping to 1 time per second. It may possibly be improved later, if needed.

MFC r317055,r317056 (glebius): Include sys/vmmeter.h as included

2018-03-15T19:08:33Z

r317055: All these files need sys/vmmeter.h, but now they got it implicitly included via sys/pcpu.h. r317056: Typo!

MFC r326067: make illumos uiocopy use vn_io_fault_uiomove

2017-12-01T11:06:51Z

MFC r325887:

2017-11-23T14:01:52Z

Avoid holding the process in uread() and uwrite().

MFC r324163: MFV r323530,r323533,r323534: 7431 ZFS Channel Programs, and followups

2017-11-08T08:53:44Z

Also MFC-ed are the following fixes: - r324164 Add several new files to the files enabled by ZFS kernel option - r324178 unbreak kernel builds on sparc64 and powerpc - r324194 fix incorrect use of getzfsvfs_impl in r324163 - r324292 really unbreak kernel builds on sparc64 and powerpc64

MFC r324425: illumos mutex_init: use SX_NEW instead of bzero

2017-10-30T10:41:01Z

MFC r324011, r324016: MFV r323535: 8585 improve batching done in zil_commit()

2017-10-30T08:53:15Z

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@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 Reviewed by: Matt Ahrens Reviewed by: George Wilson Approved by: Dan McDonald Author: Prakash Surya

MFC r323985:

2017-10-19T16:16:26Z

Use nstosbt() instead of multiplying by SBT_1NS to avoid roundoff errors. Differential Revision: https://reviews.freebsd.org/D11779

MFC r324309: remove heuristic error detection from ddi_strto*()

2017-10-19T07:21:23Z

MFC r323578,r323769: dounmount: do not release the mount point's reference

2017-10-05T06:54:25Z

on the covered vnode As long as mnt_ref is not zero there can be a consumer that might try to access mnt_vnodecovered. For this reason the covered vnode must not be freed until mnt_ref goes to zero. So, move the release of the covered vnode to vfs_mount_destroy.