ext4: Avoid scanning smaller extents in BG during CR1
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> Link: https://lore.kernel.org/r/a5473df4517c53ec940bc9b603ef83a547032a32.1685449706.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This commit is contained in:
parent
3ef5d26387
commit
1b42001121
@ -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;
|
||||
|
Loading…
Reference in New Issue
Block a user