]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit - contrib/groff/contrib/mm/examples/README
MFV 316868
authorJosh Paetzel <jpaetzel@FreeBSD.org>
Fri, 21 Apr 2017 00:12:47 +0000 (00:12 +0000)
committerJosh Paetzel <jpaetzel@FreeBSD.org>
Fri, 21 Apr 2017 00:12:47 +0000 (00:12 +0000)
commit47e222432b8c2939be0d92c64418b2355cea2c5a
tree23a7cebe935c80a16d6dc681857ea2a38e6c2f9f
parent89aa578fde959a0460e9884c3ebcd7e07d57922d
parent40e6e931e08db158d51eeeb2c377e793a2785dbb
MFV 316868

7430 Backfill metadnode more intelligently

illumos/illumos-gate@af346df58864e8fe897b1ff1a3a4c12f9294391b
https://github.com/illumos/illumos-gate/commit/af346df58864e8fe897b1ff1a3a4c12f9294391b

https://www.illumos.org/issues/7430
  Description and patch from brought over from the following ZoL commit: https://
  github.com/zfsonlinux/zfs/commit/68cbd56e182ab949f58d004778d463aeb3f595c6
  Only attempt to backfill lower metadnode object numbers if at least
  4096 objects have been freed since the last rescan, and at most once
  per transaction group. This avoids a pathology in dmu_object_alloc()
  that caused O(N^2) behavior for create-heavy workloads and
  substantially improves object creation rates. As summarized by
  @mahrens in #4636:
  "Normally, the object allocator simply checks to see if the next
  object is available. The slow calls happened when dmu_object_alloc()
  checks to see if it can backfill lower object numbers. This happens
  every time we move on to a new L1 indirect block (i.e. every 32 *
  128 = 4096 objects). When re-checking lower object numbers, we use
  the on-disk fill count (blkptr_t:blk_fill) to quickly skip over
  indirect blocks that don?t have enough free dnodes (defined as an L2
  with at least 393,216 of 524,288 dnodes free). Therefore, we may
  find that a block of dnodes has a low (or zero) fill count, and yet
  we can?t allocate any of its dnodes, because they've been allocated
  in memory but not yet written to disk. In this case we have to hold
  each of the dnodes and then notice that it has been allocated in
  memory.
  The end result is that allocating N objects in the same TXG can
  require CPU usage proportional to N^2."
  Add a tunable dmu_rescan_dnode_threshold to define the number of
  objects that must be freed before a rescan is performed. Don't bother
  to export this as a module option because testing doesn't show a
  compelling reason to change it. The vast majority of the performance
  gain comes from limit the rescan to at most once per TXG.

Reviewed by: Alek Pinchuk <alek@nexenta.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Approved by: Gordon Ross <gordon.w.ross@gmail.com>
Author: Ned Bass <bass6@llnl.gov>

Obtained from: Illumos
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_object.c
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dmu_objset.h