Hi Park, On 2017/9/26 10:36, Park Ju Hyung wrote: > GC should run conservatively as possible to reduce latency spikes to the user. > > Setting ioprio to idle class will allow the kernel to schedule GC thread's I/O > to not affect any other processes' I/O requests.
IMO, we'd better not simply changing our IO priority of background GC, because before doing real garbage collection we will try to grab gc_mutex lock, which is shared with checkpoint flow. So while background GC is running, if there it comes higher priority IOs and a sudden checkpoint, the checkpoint flow will be block for longer time when it try to grab gc_mutex, since most time checkpoint comes from foreground application, so it may effects user experience. What about adding IO aware point before triggering each IO inside GC flow, and when it hits other IO, let's give up background GC? Thanks, > > Signed-off-by: Park Ju Hyung <[email protected]> > --- > fs/f2fs/gc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c > index bfe6a8ccc3a0..54d2d74e9afe 100644 > --- a/fs/f2fs/gc.c > +++ b/fs/f2fs/gc.c > @@ -143,6 +143,8 @@ int start_gc_thread(struct f2fs_sb_info *sbi) > kfree(gc_th); > sbi->gc_thread = NULL; > } > + set_task_ioprio(sbi->gc_thread->f2fs_gc_task, > + IOPRIO_PRIO_VALUE(IOPRIO_CLASS_IDLE, 0)); > out: > return err; > } > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
