Hi Daejun, On 06/14, Daejun Park wrote: > Hi Jaegeuk, > > > If there're huge # of small discards, this will increase checkpoint latency > > insanely. Let's issue small discards only by trim. > > > > Signed-off-by: Jaegeuk Kim <jaeg...@kernel.org> > > --- > > fs/f2fs/segment.c | 5 ++--- > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c > > index 0c0c033c4bdd..ef46bb085385 100644 > > --- a/fs/f2fs/segment.c > > +++ b/fs/f2fs/segment.c > > @@ -2178,7 +2178,7 @@ void f2fs_clear_prefree_segments(struct f2fs_sb_info > > *sbi, > > } > > mutex_unlock(&dirty_i->seglist_lock); > > > > - if (!f2fs_block_unit_discard(sbi)) > > + if (!f2fs_block_unit_discard(sbi) || !force) > > If we don't handle the discard entries here, dcc->entry_list will still have > them, > so stale discard entries may be handled by trim, causing incorrect discards > to be issued. > Therefore, I think this patch should also prevent the creation of discard > entries > in add_discard_addrs(), unless it is a checkpoint caused by trim. > This would further reduce the latency caused by the creation of a discard > entry.
I found this causes some objects were not reclaimed when removing the module. Hence I'm testing v2. > > Thanks, > Daejun > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
