From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hou Pengyang Subject: Re: [PATCH] f2fs: avoid unnecessary fg_gc Date: Mon, 27 Feb 2017 09:59:09 +0800 Message-ID: <58B387ED.8080700@huawei.com> References: <20170224100135.70000-1-houpengyang@huawei.com> <0486c0d4-541c-ee21-c598-6656a291a274@huawei.com> <58B0E17C.1030306@huawei.com> <20170225020733.GB50867@jaegeuk.local> <20170225193959.GE51627@jaegeuk.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1ciAb9-0007nr-9U for linux-f2fs-devel@lists.sourceforge.net; Mon, 27 Feb 2017 01:59:35 +0000 Received: from [45.249.212.188] (helo=dggrg02-dlp.huawei.com) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1ciAb6-0002Yz-J8 for linux-f2fs-devel@lists.sourceforge.net; Mon, 27 Feb 2017 01:59:35 +0000 In-Reply-To: <20170225193959.GE51627@jaegeuk.local> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net To: Jaegeuk Kim Cc: guoweichao@huawei.com, linux-f2fs-devel@lists.sourceforge.net On 2017/2/26 3:39, Jaegeuk Kim wrote: > On 02/25, heyunlei wrote: >> Hi all, >> >> I am really confused by the condition below use sec_freed, is it always equal to zero? > > Seems it is always zero. Let's fix it together. > > Pengyang, > > I merged your patches and finally got this. > How do you think? > Seems OK to me :) Thanks, >>>From d1c2206e4f245a8fedec3a8f21ad522b3b1b2d0c Mon Sep 17 00:00:00 2001 > From: Hou Pengyang > Date: Sat, 25 Feb 2017 03:57:38 +0000 > Subject: [PATCH] f2fs: avoid bggc->fggc when enough free segments are > avaliable after cp > > We use has_not_enough_free_secs to check if there are enough free segments, > > (free_sections(sbi) + freed) <= > (node_secs + 2 * dent_secs + imeta_secs + > reserved_sections(sbi) + needed); > > Under scenario with large number of dirty nodes, these nodes would be flushed > during cp, as a result, right side of the inequality would be decreased, while > left side stays unchanged if these nodes are flushed in SSR way, which means > there are enough free segments after this cp. > > For this case, we just do a bggc instead of fggc. > > Signed-off-by: Hou Pengyang > Signed-off-by: Jaegeuk Kim > --- > fs/f2fs/gc.c | 17 +++++++++-------- > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c > index 1af17c5af603..471ed899f639 100644 > --- a/fs/f2fs/gc.c > +++ b/fs/f2fs/gc.c > @@ -954,21 +954,22 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync, bool background) > goto stop; > } > > - if (gc_type == BG_GC && has_not_enough_free_secs(sbi, sec_freed, 0)) { > - gc_type = FG_GC; > + if (gc_type == BG_GC && has_not_enough_free_secs(sbi, 0, 0)) { > /* > - * If there is no victim and no prefree segment but still not > - * enough free sections, we should flush dent/node blocks and do > - * garbage collections. > + * For example, if there are many prefree_segments below given > + * threshold, we can make them free by checkpoint. Then, we > + * secure free segments which doesn't need fggc any more. > */ > ret = write_checkpoint(sbi, &cpc); > if (ret) > goto stop; > - } else if (gc_type == BG_GC && !background) { > - /* f2fs_balance_fs doesn't need to do BG_GC in critical path. */ > - goto stop; > + if (has_not_enough_free_secs(sbi, 0, 0)) > + gc_type = FG_GC; > } > > + /* f2fs_balance_fs doesn't need to do BG_GC in critical path. */ > + if (gc_type == BG_GC && !background) > + goto stop; > if (!__get_victim(sbi, &segno, gc_type)) > goto stop; > ret = 0; > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot