From: Ojaswin Mujoo <ojaswin@linux.ibm.com>
To: linux-ext4@vger.kernel.org, "Theodore Ts'o" <tytso@mit.edu>
Cc: Ritesh Harjani <riteshh@linux.ibm.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Jan Kara <jack@suse.cz>, Kemeng Shi <shikemeng@huaweicloud.com>,
Ritesh Harjani <ritesh.list@gmail.com>
Subject: [PATCH 08/13] ext4: Avoid scanning smaller extents in BG during CR1
Date: Thu, 25 May 2023 17:03:02 +0530 [thread overview]
Message-ID: <b39b81f92eb5fc4544d52eaaa5942c22e5ce378f.1685009579.git.ojaswin@linux.ibm.com> (raw)
In-Reply-To: <cover.1685009579.git.ojaswin@linux.ibm.com>
When we are inside ext4_mb_complex_scan_group() in CR1, we can be sure
that this group has atleast 1 big enough continuous free extent to satisfy
our request because (free / fragments) > goal length.
Hence, instead of wasting time looping over smaller free extents, only
try to consider the free extent if we are sure that it has enough
continuous free space to satisfy goal length. This is particularly
useful when scanning highly fragmented BGs in CR1 as, without this
patch, the allocator might stop scanning early before reaching the big
enough free extent (due to ac_found > mb_max_to_scan) which causes us to
uncessarily trim the request.
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
---
fs/ext4/mballoc.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 8786aa0dd57a..855fb7d440f1 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2307,7 +2307,7 @@ void ext4_mb_complex_scan_group(struct ext4_allocation_context *ac,
struct super_block *sb = ac->ac_sb;
void *bitmap = e4b->bd_bitmap;
struct ext4_free_extent ex;
- int i;
+ int i, j, freelen;
int free;
free = e4b->bd_info->bb_free;
@@ -2334,6 +2334,23 @@ void ext4_mb_complex_scan_group(struct ext4_allocation_context *ac,
break;
}
+ if (ac->ac_criteria < CR2) {
+ /*
+ * In CR1, we are sure that this group will
+ * have a large enough continuous free extent, so skip
+ * over the smaller free extents
+ */
+ j = mb_find_next_bit(bitmap,
+ EXT4_CLUSTERS_PER_GROUP(sb), i);
+ freelen = j - i;
+
+ if (freelen < ac->ac_g_ex.fe_len) {
+ i = j;
+ free -= freelen;
+ continue;
+ }
+ }
+
mb_find_extent(e4b, i, ac->ac_g_ex.fe_len, &ex);
if (WARN_ON(ex.fe_len <= 0))
break;
--
2.31.1
next prev parent reply other threads:[~2023-05-25 11:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-25 11:32 [PATCH 00/13] multiblock allocator improvements Ojaswin Mujoo
2023-05-25 11:32 ` [PATCH 01/13] Revert "ext4: remove ac->ac_found > sbi->s_mb_min_to_scan dead check in ext4_mb_check_limits" Ojaswin Mujoo
2023-05-25 12:24 ` Kemeng Shi
2023-06-02 13:41 ` Linux regression tracking #adding (Thorsten Leemhuis)
2023-05-25 11:32 ` [PATCH 02/13] ext4: mballoc: Remove useless setting of ac_criteria Ojaswin Mujoo
2023-05-25 11:32 ` [PATCH 03/13] ext4: Remove unused extern variables declaration Ojaswin Mujoo
2023-05-25 11:32 ` [PATCH 04/13] ext4: Fix a small typo in ext4_mb_prefetch_fini() Ojaswin Mujoo
2023-05-25 11:32 ` [PATCH 05/13] ext4: Convert mballoc cr (criteria) to enum Ojaswin Mujoo
2023-05-25 11:33 ` [PATCH 06/13] ext4: Add per CR extent scanned counter Ojaswin Mujoo
2023-05-25 11:33 ` [PATCH 07/13] ext4: Add counter to track successful allocation of goal length Ojaswin Mujoo
2023-05-25 11:33 ` Ojaswin Mujoo [this message]
2023-05-25 11:33 ` [PATCH 09/13] ext4: Don't skip prefetching BLOCK_UNINIT groups Ojaswin Mujoo
2023-05-25 11:33 ` [PATCH 10/13] ext4: Ensure ext4_mb_prefetch_fini() is called for all prefetched BGs Ojaswin Mujoo
2023-05-25 11:33 ` [PATCH 11/13] ext4: Abstract out logic to search average fragment list Ojaswin Mujoo
2023-05-25 11:33 ` [PATCH 12/13] ext4: Add allocation criteria 1.5 (CR1_5) Ojaswin Mujoo
2023-05-25 11:33 ` [PATCH 13/13] ext4: Give symbolic names to mballoc criterias Ojaswin Mujoo
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=b39b81f92eb5fc4544d52eaaa5942c22e5ce378f.1685009579.git.ojaswin@linux.ibm.com \
--to=ojaswin@linux.ibm.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ritesh.list@gmail.com \
--cc=riteshh@linux.ibm.com \
--cc=shikemeng@huaweicloud.com \
--cc=tytso@mit.edu \
/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
all inboxes | Powered by JetHome®