git: hammer2 - Fix excess chain structure allocations during bulkfree (2)

[Matthew Dillon]

commit 784d105b6000afc68e4b26e8acf5b4d6a79ea1f7
Author: Matthew Dillon <dillon at apollo.backplane.com>
Date:   Fri Jan 14 12:55:36 2022 -0800

    hammer2 - Fix excess chain structure allocations during bulkfree (2)
    
    Try to fix this again.  The last attempt failed.  Basically the
    problem is that when the depth-first traversal gets too deep, it
    has to defer the node at that point by adding it to a list.
    
    * Change the order to insert deferrals on the head instead of the
      tail in order to exhaust the most recently deferred sub-tree as
      quickly as possible (LIFO order).  We previously exhausted deferred
      sub-trees in FIFO order but this often resulted in multiple levels
      of the radix tree building up on the list, which could blow-up
      memory use.
    
    * Once the list limit is reached (well, really 1/4 of the list limit),
      we previously continued to accumulate deferral as long as the
      relative depth was less then 3.  Unfortunately, the maximum radix
      tree table size of roughly 512 elements could cause the number
      of deferrals even after the limit was reached to be up to
      134 million chains (512 * 512 * 512).
    
      This is fixed by removing any depth test when the list limit is
      exhausted.
    
    * This combination of fixes should prevent the number of deferrals
      from blowing out hammer2's kmalloc pool.  Theoretically the
      worst-case possible deferrals should now be 512 chains x max depth
      of radix tree.  A very reasonable number.

Summary of changes:
 sys/vfs/hammer2/hammer2.h          |  1 +
 sys/vfs/hammer2/hammer2_bulkfree.c | 51 ++++++++++++++++++++++++++++----------
 sys/vfs/hammer2/hammer2_vfsops.c   |  3 +++
 3 files changed, 42 insertions(+), 13 deletions(-)

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/784d105b6000afc68e4b26e8acf5b4d6a79ea1f7


-- 
DragonFly BSD source repository