Hi ext4 developers,
I looked into problem with long time allocations with large FS and found a some strange in
commit
commit 40ae3487628235e5f1eb27542cca0cdb6e5dbe16
Author: Theodore Ts'o <tytso@xxxxxxx>
Date: Mon Feb 4 15:08:40 2013 -0500
ext4: optimize mballoc for large allocations
..
it have a chunk
@@ -1884,15 +1884,19 @@ static int ext4_mb_good_group(struct ext4_allocation_context *ac,
case 0:
BUG_ON(ac->ac_2order == 0);
- if (grp->bb_largest_free_order < ac->ac_2order)
- return 0;
-
/* Avoid using the first bg of a flexgroup for data files */
if ((ac->ac_flags & EXT4_MB_HINT_DATA) &&
(flex_size >= EXT4_FLEX_SIZE_DIR_ALLOC_SCHEME) &&
((group % flex_size) == 0))
return 0;
+ if ((ac->ac_2order > ac->ac_sb->s_blocksize_bits+1) ||
+ (free / fragments) >= ac->ac_g_ex.fe_len) <<<< (0)
+ return 1;
+
+ if (grp->bb_largest_free_order < ac->ac_2order)
+ return 0;
+
return 1;
case 1:
if ((free / fragments) >= ac->ac_g_ex.fe_len) (1)
..
ac_g_ex isn’t changed between loops, free/fragments is also don’t changed.
i this case loop(1) is useless as same condition as used in loop (0), but it’s will eats a some time with large number a group.
In this case - i think loop(1) can be cut and save a some time with scanning a groups.
Theo, what you think about that change ?
Alex
