Btrfs: stop using GFP_ATOMIC for the tree mod log allocations
authorJosef Bacik <jbacik@fusionio.com>
Mon, 1 Jul 2013 20:18:19 +0000 (16:18 -0400)
committerChris Mason <chris.mason@fusionio.com>
Sun, 1 Sep 2013 11:57:17 +0000 (07:57 -0400)
commitc8cc6341653721b54760480b0d0d9b5f09b46741
tree210311dd6ebe33d94955eb7a0a1ad8408ec5023b
parentd8dfad3876e4386666b759da3c833d62fb8b2267
Btrfs: stop using GFP_ATOMIC for the tree mod log allocations

Previously we held the tree mod lock when adding stuff because we use it to
check and see if we truly do want to track tree modifications.  This is
admirable, but GFP_ATOMIC in a critical area that is going to get hit pretty
hard and often is not nice.  So instead do our basic checks to see if we don't
need to track modifications, and if those pass then do our allocation, and then
when we go to insert the new modification check if we still care, and if we
don't just free up our mod and return.  Otherwise we're good to go and we can
carry on.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
fs/btrfs/ctree.c