All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH 5/9] btrfs: rework btrfs_calc_reclaim_metadata_size
Date: Wed, 30 Sep 2020 16:01:05 -0400	[thread overview]
Message-ID: <bc6b0eeceacb2b444acf1ff74673471e2dfd2bb9.1601495426.git.josef@toxicpanda.com> (raw)
In-Reply-To: <cover.1601495426.git.josef@toxicpanda.com>

Currently btrfs_calc_reclaim_metadata_size does two things, it returns
the space currently required for flushing by the tickets, and if there
are no tickets it calculates a value for the preemptive flushing.

However for the normal ticketed flushing we really only care about the
space required for tickets.  We will accidentally come in and flush one
time, but as soon as we see there are no tickets we bail out of our
flushing.

Fix this by making btrfs_calc_reclaim_metadata_size really only tell us
what is required for flushing if we have people waiting on space.  Then
move the preemptive flushing logic into need_preemptive_reclaim().  We
ignore btrfs_calc_reclaim_metadata_size() in need_preemptive_reclaim()
because if we are in this path then we made our reservation and there
are not pending tickets currently, so we do not need to check it, simply
do the fuzzy logic to check if we're getting low on space.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/space-info.c | 44 ++++++++++++++++++++-----------------------
 1 file changed, 20 insertions(+), 24 deletions(-)

diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c
index 518749093bc5..37eb5a11a875 100644
--- a/fs/btrfs/space-info.c
+++ b/fs/btrfs/space-info.c
@@ -752,7 +752,6 @@ btrfs_calc_reclaim_metadata_size(struct btrfs_fs_info *fs_info,
 {
 	u64 used;
 	u64 avail;
-	u64 expected;
 	u64 to_reclaim = space_info->reclaim_size;
 
 	lockdep_assert_held(&space_info->lock);
@@ -770,28 +769,6 @@ btrfs_calc_reclaim_metadata_size(struct btrfs_fs_info *fs_info,
 	if (space_info->total_bytes + avail < used)
 		to_reclaim += used - (space_info->total_bytes + avail);
 
-	if (to_reclaim)
-		return to_reclaim;
-
-	to_reclaim = min_t(u64, num_online_cpus() * SZ_1M, SZ_16M);
-	if (btrfs_can_overcommit(fs_info, space_info, to_reclaim,
-				 BTRFS_RESERVE_FLUSH_ALL))
-		return 0;
-
-	used = btrfs_space_info_used(space_info, true);
-
-	if (btrfs_can_overcommit(fs_info, space_info, SZ_1M,
-				 BTRFS_RESERVE_FLUSH_ALL))
-		expected = div_factor_fine(space_info->total_bytes, 95);
-	else
-		expected = div_factor_fine(space_info->total_bytes, 90);
-
-	if (used > expected)
-		to_reclaim = used - expected;
-	else
-		to_reclaim = 0;
-	to_reclaim = min(to_reclaim, space_info->bytes_may_use +
-				     space_info->bytes_reserved);
 	return to_reclaim;
 }
 
@@ -800,6 +777,7 @@ static inline int need_preemptive_reclaim(struct btrfs_fs_info *fs_info,
 					  u64 used)
 {
 	u64 thresh = div_factor_fine(space_info->total_bytes, 98);
+	u64 to_reclaim, expected;
 
 	/* If we're just plain full then async reclaim just slows us down. */
 	if ((space_info->bytes_used + space_info->bytes_reserved) >= thresh)
@@ -812,7 +790,25 @@ static inline int need_preemptive_reclaim(struct btrfs_fs_info *fs_info,
 	if (space_info->reclaim_size)
 		return 0;
 
-	if (!btrfs_calc_reclaim_metadata_size(fs_info, space_info))
+	to_reclaim = min_t(u64, num_online_cpus() * SZ_1M, SZ_16M);
+	if (btrfs_can_overcommit(fs_info, space_info, to_reclaim,
+				 BTRFS_RESERVE_FLUSH_ALL))
+		return 0;
+
+	used = btrfs_space_info_used(space_info, true);
+	if (btrfs_can_overcommit(fs_info, space_info, SZ_1M,
+				 BTRFS_RESERVE_FLUSH_ALL))
+		expected = div_factor_fine(space_info->total_bytes, 95);
+	else
+		expected = div_factor_fine(space_info->total_bytes, 90);
+
+	if (used > expected)
+		to_reclaim = used - expected;
+	else
+		to_reclaim = 0;
+	to_reclaim = min(to_reclaim, space_info->bytes_may_use +
+				     space_info->bytes_reserved);
+	if (!to_reclaim)
 		return 0;
 
 	return (used >= thresh && !btrfs_fs_closing(fs_info) &&
-- 
2.26.2


  parent reply	other threads:[~2020-09-30 20:01 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30 20:01 [PATCH 0/9] Improve preemptive ENOSPC flushing Josef Bacik
2020-09-30 20:01 ` [PATCH 1/9] btrfs: add a trace point for reserve tickets Josef Bacik
2020-10-01  5:54   ` Nikolay Borisov
2020-10-01 21:33     ` Josef Bacik
2020-09-30 20:01 ` [PATCH 2/9] btrfs: improve preemptive background space flushing Josef Bacik
2020-10-01 13:19   ` Nikolay Borisov
2020-10-01 21:35     ` Josef Bacik
2020-09-30 20:01 ` [PATCH 3/9] btrfs: rename need_do_async_reclaim Josef Bacik
2020-10-01 13:20   ` Nikolay Borisov
2020-10-01 13:24   ` Nikolay Borisov
2020-10-01 21:37     ` Josef Bacik
2020-09-30 20:01 ` [PATCH 4/9] btrfs: check reclaim_size in need_preemptive_reclaim Josef Bacik
2020-10-01 13:23   ` Nikolay Borisov
2020-10-01 21:36     ` Josef Bacik
2020-09-30 20:01 ` Josef Bacik [this message]
2020-10-01 13:59   ` [PATCH 5/9] btrfs: rework btrfs_calc_reclaim_metadata_size Nikolay Borisov
2020-10-01 21:38     ` Josef Bacik
2020-09-30 20:01 ` [PATCH 6/9] btrfs: simplify the logic in need_preemptive_flushing Josef Bacik
2020-10-01 14:09   ` Nikolay Borisov
2020-10-01 21:40     ` Josef Bacik
2020-10-02  7:13   ` Nikolay Borisov
2020-09-30 20:01 ` [PATCH 7/9] btrfs: implement space clamping for preemptive flushing Josef Bacik
2020-10-01 14:49   ` Nikolay Borisov
2020-10-01 21:41     ` Josef Bacik
2020-09-30 20:01 ` [PATCH 8/9] btrfs: adjust the flush trace point to include the source Josef Bacik
2020-10-01 15:32   ` Nikolay Borisov
2020-09-30 20:01 ` [PATCH 9/9] btrfs: add a trace class for dumping the current ENOSPC state Josef Bacik
2020-10-02  8:30   ` Nikolay Borisov
2020-10-02 13:45     ` Josef Bacik
2020-10-06 12:55 ` [PATCH 0/9] Improve preemptive ENOSPC flushing Nikolay Borisov

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=bc6b0eeceacb2b444acf1ff74673471e2dfd2bb9.1601495426.git.josef@toxicpanda.com \
    --to=josef@toxicpanda.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.