btrfs: check for priority ticket granting before flushing
authorJosef Bacik <josef@toxicpanda.com>
Tue, 9 Nov 2021 15:12:02 +0000 (10:12 -0500)
committerDavid Sterba <dsterba@suse.com>
Mon, 3 Jan 2022 14:09:45 +0000 (15:09 +0100)
commit9cd8dcdc5e5c459bcd01a97c8c8d6bc2c8d73fdf
treebd42346a38f42f01d5216ee2e362043f69d3f85d
parent9f35f76d7df66507b698ac7298fb6c175a6aae7d
btrfs: check for priority ticket granting before flushing

Since we're dropping locks before we enter the priority flushing loops
we could have had our ticket granted before we got the space_info->lock.
So add this check to avoid doing some extra flushing in the priority
flushing cases.

The case in priority_reclaim_metadata_space is an optimization.  Think
we came in to reserve, we didn't have the space, we added our ticket to
the list.  But at the same time somebody was waiting on the space_info
lock to add space and do btrfs_try_granting_ticket(), so we drop the
lock, get satisfied, come in to do our loop, and we have been
satisfied.

This is the priority reclaim path, so to_reclaim could be !0 still
because we may have only satisfied the priority tickets and still left
non priority tickets on the list.  We would then have to_reclaim but
->bytes == 0.

Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
[ add note about the optimization ]
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/space-info.c