]> git.baikalelectronics.ru Git - kernel.git/commit
Btrfs: reduce btree node locking duration on item update
authorFilipe David Borba Manana <fdmanana@gmail.com>
Mon, 23 Dec 2013 11:53:02 +0000 (11:53 +0000)
committerChris Mason <clm@fb.com>
Tue, 28 Jan 2014 21:20:11 +0000 (13:20 -0800)
commitc718e6e8e5cff5a2f293d3f882c4916c3aff6d77
tree26e4b083c59dc9a7687ca1a533a01eb4762aac9f
parentd8f2de334c5731f1a6c276b00774254abbd49fab
Btrfs: reduce btree node locking duration on item update

If we do a btree search with the goal of updating an existing item
without changing its size (ins_len == 0 and cow == 1), then we never
need to hold locks on upper level nodes (even when slot == 0) after we
COW their child nodes/leaves, as we won't have node splits or merges
in this scenario (that is, no key additions, removals or shifts on any
nodes or leaves).

Therefore release the locks immediately after COWing the child nodes/leaves
while navigating the btree, even if their parent slot is 0, instead of
returning a path to the caller with those nodes locked, which would get
released only when the caller releases or frees the path (or if it calls
btrfs_unlock_up_safe).

This is a common scenario, for example when updating inode items in fs
trees and block group items in the extent tree.

The following benchmarks were performed on a quad core machine with 32Gb
of ram, using a leaf/node size of 4Kb (to generate deeper fs trees more
quickly).

  sysbench --test=fileio --file-num=131072 --file-total-size=8G \
    --file-test-mode=seqwr --num-threads=512 --file-block-size=8192 \
    --max-requests=100000 --file-io-mode=sync [prepare|run]

Before this change:  49.85Mb/s (average of 5 runs)
After this change:   50.38Mb/s (average of 5 runs)

Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
fs/btrfs/ctree.c
fs/btrfs/inode.c