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>, Ritesh Harjani <ritesh.list@gmail.com>
Subject: [RFC 07/11] ext4: Avoid scanning smaller extents in BG during CR1
Date: Fri, 27 Jan 2023 18:07:34 +0530 [thread overview]
Message-ID: <6fefb97af05081d344185334a36e90f093ccf310.1674822311.git.ojaswin@linux.ibm.com> (raw)
In-Reply-To: <cover.1674822311.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>
---
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 c4ab8f412d32..14529d2fe65f 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2279,7 +2279,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;
@@ -2306,6 +2306,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-01-27 12:39 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-27 12:37 [RFC 00/11] multiblock allocator improvements Ojaswin Mujoo
2023-01-27 12:37 ` [RFC 01/11] ext4: mballoc: Remove useless setting of ac_criteria Ojaswin Mujoo
2023-03-09 11:36 ` Jan Kara
2023-01-27 12:37 ` [RFC 02/11] ext4: Remove unused extern variables declaration Ojaswin Mujoo
2023-03-09 11:37 ` Jan Kara
2023-01-27 12:37 ` [RFC 03/11] ext4: mballoc: Fix getting the right group desc in ext4_mb_prefetch_fini Ojaswin Mujoo
2023-03-09 11:42 ` Jan Kara
2023-01-27 12:37 ` [RFC 04/11] ext4: Convert mballoc cr (criteria) to enum Ojaswin Mujoo
2023-03-09 12:11 ` Jan Kara
2023-03-17 10:26 ` Ojaswin Mujoo
2023-03-23 10:55 ` Jan Kara
2023-03-25 14:42 ` Ojaswin Mujoo
2023-04-20 6:32 ` Ojaswin Mujoo
2023-04-20 14:58 ` Jan Kara
2023-01-27 12:37 ` [RFC 05/11] ext4: Add per CR extent scanned counter Ojaswin Mujoo
2023-03-09 12:14 ` Jan Kara
2023-01-27 12:37 ` [RFC 06/11] ext4: Add counter to track successful allocation of goal length Ojaswin Mujoo
2023-03-09 12:17 ` Jan Kara
2023-01-27 12:37 ` Ojaswin Mujoo [this message]
2023-03-09 12:20 ` [RFC 07/11] ext4: Avoid scanning smaller extents in BG during CR1 Jan Kara
2023-01-27 12:37 ` [RFC 08/11] ext4: Don't skip prefetching BLOCK_UNINIT groups Ojaswin Mujoo
2023-03-09 14:14 ` Jan Kara
2023-03-17 10:55 ` Ojaswin Mujoo
2023-03-23 10:57 ` Jan Kara
2023-03-25 14:43 ` Ojaswin Mujoo
2023-03-26 3:54 ` Theodore Ts'o
2023-01-27 12:37 ` [RFC 09/11] ext4: Ensure ext4_mb_prefetch_fini() is called for all prefetched BGs Ojaswin Mujoo
2023-03-09 14:23 ` Jan Kara
2023-01-27 12:37 ` [RFC 10/11] ext4: Abstract out logic to search average fragment list Ojaswin Mujoo
2023-03-09 14:25 ` Jan Kara
2023-01-27 12:37 ` [RFC 11/11] ext4: Add allocation criteria 1.5 (CR1_5) Ojaswin Mujoo
2023-03-09 15:06 ` Jan Kara
2023-03-17 11:37 ` Ojaswin Mujoo
2023-03-23 11:05 ` Jan Kara
2023-03-25 14:46 ` 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=6fefb97af05081d344185334a36e90f093ccf310.1674822311.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=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®