On 2020/2/19 7:27, Jaegeuk Kim wrote: > On 02/17, Chao Yu wrote: >> On 2020/2/15 2:58, Jaegeuk Kim wrote: >>> FG_GC needs to move entire section more quickly. >>> >>> Signed-off-by: Jaegeuk Kim <jaeg...@kernel.org> >>> --- >>> fs/f2fs/gc.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c >>> index bbf4db3f6bb4..1676eebc8c8b 100644 >>> --- a/fs/f2fs/gc.c >>> +++ b/fs/f2fs/gc.c >>> @@ -1203,7 +1203,7 @@ static int do_garbage_collect(struct f2fs_sb_info >>> *sbi, >>> >>> if (get_valid_blocks(sbi, segno, false) == 0) >>> goto freed; >>> - if (__is_large_section(sbi) && >>> + if (gc_type == BG_GC && __is_large_section(sbi) && >>> migrated >= sbi->migration_granularity) >> >> I knew migrating one large section is a more efficient way, but this can >> increase long-tail latency of f2fs_balance_fs() occasionally, especially in >> extreme fragmented space. > > FG_GC requires to wait for whole section migration which shows the entire > latency.
That will cause long-tail latency for single f2fs_balance_fs() procedure, which it looks a very long hang when userspace call f2fs syscall, so why not splitting total elapsed time into several f2fs_balance_fs() to avoid that. Thanks, > >> >> Thanks, >> >>> goto skip; >>> if (!PageUptodate(sum_page) || unlikely(f2fs_cp_error(sbi))) >>> > . > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
