git: hammer2 - Fix excess chain structure allocations during bulkfree (2)
Matthew Dillon
dillon at crater.dragonflybsd.org
Sun Jan 23 22:06:47 PST 2022
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
More information about the Commits
mailing list