linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boris Burkov <boris@bur.io>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH] btrfs: skip reclaim if block_group is empty
Date: Mon, 10 Oct 2022 11:49:51 -0700	[thread overview]
Message-ID: <8f825fce9d2968034da43e09a4ebc38ec19a2e49.1665427766.git.boris@bur.io> (raw)

As we delete extents from a block group, at some deletion we cross below
the reclaim threshold. It is possible we are still in the middle of
deleting more extents and might soon hit 0. If that occurs, we would
leave the block group on the reclaim list, not in the care of unused
deletion or async discard.

It is pointless and wasteful to relocate empty block groups, so if we do
notice that case (we might not if the reclaim worker runs *before* we
finish emptying it), don't bother with relocating the block group.

Signed-off-by: Boris Burkov <boris@bur.io>
---
 fs/btrfs/block-group.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
index 11fd52657b76..c3ea627d2457 100644
--- a/fs/btrfs/block-group.c
+++ b/fs/btrfs/block-group.c
@@ -1608,6 +1608,25 @@ void btrfs_reclaim_bgs_work(struct work_struct *work)
 			up_write(&space_info->groups_sem);
 			goto next;
 		}
+		if (bg->used == 0) {
+			/*
+			 * It is possible that we trigger relocation on a block
+			 * group as its extents are deleted and it first goes
+			 * below the threshold, then shortly goes empty. In that
+			 * case, we will do relocation, even though we could
+			 * more cheaply just delete the unused block group. Try
+			 * to catch that case here, though of course it is
+			 * possible there is a delete still coming the future,
+			 * so we can't avoid needless relocation of this sort
+			 * altogether. We can at least avoid relocating empty
+			 * block groups.
+			 */
+			if (!btrfs_test_opt(fs_info, DISCARD_ASYNC))
+				btrfs_mark_bg_unused(bg);
+			spin_unlock(&bg->lock);
+			up_write(&space_info->groups_sem);
+			goto next;
+		}
 		spin_unlock(&bg->lock);
 
 		/* Get out fast, in case we're unmounting the filesystem */
-- 
2.37.2


             reply	other threads:[~2022-10-10 18:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-10 18:49 Boris Burkov [this message]
2022-10-11  9:43 ` [PATCH] btrfs: skip reclaim if block_group is empty Filipe Manana
2022-10-11 18:05   ` Boris Burkov
2022-10-12  9:51     ` Filipe Manana

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8f825fce9d2968034da43e09a4ebc38ec19a2e49.1665427766.git.boris@bur.io \
    --to=boris@bur.io \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).