From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 128A7C4CEC7 for ; Mon, 16 Sep 2019 01:23:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E7FBA20830 for ; Mon, 16 Sep 2019 01:23:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729112AbfIPBXN (ORCPT ); Sun, 15 Sep 2019 21:23:13 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:2271 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728872AbfIPBXM (ORCPT ); Sun, 15 Sep 2019 21:23:12 -0400 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id AD0EDE2B2C97BAF21A9E; Mon, 16 Sep 2019 09:23:10 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.213) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 16 Sep 2019 09:23:06 +0800 Subject: Re: [f2fs-dev] [PATCH 1/2] f2fs: do not select same victim right again To: Jaegeuk Kim CC: , References: <20190909012532.20454-1-jaegeuk@kernel.org> <69933b7f-48cc-47f9-ba6f-b5ca8f733cba@huawei.com> <20190909080654.GD21625@jaegeuk-macbookpro.roam.corp.google.com> <97237da2-897a-8420-94de-812e94aa751f@huawei.com> <20190909120443.GA31108@jaegeuk-macbookpro.roam.corp.google.com> From: Chao Yu Message-ID: <27725e65-53fe-5731-0201-9959b8ef6b49@huawei.com> Date: Mon, 16 Sep 2019 09:22:51 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190909120443.GA31108@jaegeuk-macbookpro.roam.corp.google.com> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/9/9 20:04, Jaegeuk Kim wrote: > On 09/09, Chao Yu wrote: >> On 2019/9/9 16:06, Jaegeuk Kim wrote: >>> On 09/09, Chao Yu wrote: >>>> On 2019/9/9 9:25, Jaegeuk Kim wrote: >>>>> GC must avoid select the same victim again. >>>> >>>> Blocks in previous victim will occupy addition free segment, I doubt after this >>>> change, FGGC may encounter out-of-free space issue more frequently. >>> >>> Hmm, actually this change seems wrong by sec_usage_check(). >>> We may be able to avoid this only in the suspicious loop? >>> >>> --- >>> 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 e88f98ddf396..5877bd729689 100644 >>> --- a/fs/f2fs/gc.c >>> +++ b/fs/f2fs/gc.c >>> @@ -1326,7 +1326,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync, >>> round++; >>> } >>> >>> - if (gc_type == FG_GC) >>> + if (gc_type == FG_GC && seg_freed) >> >> That's original solution Sahitya provided to avoid infinite loop of GC, but I >> suggest to find the root cause first, then we added .invalid_segmap for that >> purpose. > > I've checked the Sahitya's patch. So, it seems the problem can happen due to > is_alive or atomic_file. For some conditions, this doesn't help, for example, two sections contain the same fewest valid blocks, it will cause to loop selecting them if it fails to migrate blocks. How about keeping it as it is to find potential bug. Thanks, > >> >> Thanks, >> >>> sbi->cur_victim_sec = NULL_SEGNO; >>> >>> if (sync) >>> > . > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F150C4CEC4 for ; Mon, 16 Sep 2019 01:23:24 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D0D9120830; Mon, 16 Sep 2019 01:23:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="eVucRYRp"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="EZ/lC2DY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D0D9120830 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1i9fjf-0003Tc-7W; Mon, 16 Sep 2019 01:23:23 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1i9fjd-0003TU-86 for linux-f2fs-devel@lists.sourceforge.net; Mon, 16 Sep 2019 01:23:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:CC:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=YdC96T0MRe8fklzxO77o/53RvVritoqGgZsDTdmAd+Y=; b=eVucRYRp+55HXcWFx2kghH5oxT VpWPGVfXMjvisJaj11RnvVGoY4rRVenQyYTqceeLSRmIPWgyGeBZxX0+Rvq5IKuqTcETfFeCjFsaJ PXwCQuyF0PwGbqp8d50uiRrui0fGtDsDezWuuBrL6EOT4JyQ98G/ealQFDYPHuI05FUA=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:CC:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YdC96T0MRe8fklzxO77o/53RvVritoqGgZsDTdmAd+Y=; b=EZ/lC2DYqyVHWdonHQebatO2Xl g38witXwyZZ/W3hiwJNPrfAxJyUuKSwn2tn4v54eKLFEY/0S6kx02WUMiAKEV13cDr9XQBnu/e5Lc q4TfL0eMivh28doA6gH/mZR/1d38ZCCc4JBDNu2qBg8TjeudMqHi/cCp8CB9aqMjkxso=; Received: from szxga05-in.huawei.com ([45.249.212.191] helo=huawei.com) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) id 1i9fjb-0072GL-QO for linux-f2fs-devel@lists.sourceforge.net; Mon, 16 Sep 2019 01:23:21 +0000 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id AD0EDE2B2C97BAF21A9E; Mon, 16 Sep 2019 09:23:10 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.213) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 16 Sep 2019 09:23:06 +0800 To: Jaegeuk Kim References: <20190909012532.20454-1-jaegeuk@kernel.org> <69933b7f-48cc-47f9-ba6f-b5ca8f733cba@huawei.com> <20190909080654.GD21625@jaegeuk-macbookpro.roam.corp.google.com> <97237da2-897a-8420-94de-812e94aa751f@huawei.com> <20190909120443.GA31108@jaegeuk-macbookpro.roam.corp.google.com> From: Chao Yu Message-ID: <27725e65-53fe-5731-0201-9959b8ef6b49@huawei.com> Date: Mon, 16 Sep 2019 09:22:51 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190909120443.GA31108@jaegeuk-macbookpro.roam.corp.google.com> Content-Language: en-US X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected X-Headers-End: 1i9fjb-0072GL-QO Subject: Re: [f2fs-dev] [PATCH 1/2] f2fs: do not select same victim right again X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On 2019/9/9 20:04, Jaegeuk Kim wrote: > On 09/09, Chao Yu wrote: >> On 2019/9/9 16:06, Jaegeuk Kim wrote: >>> On 09/09, Chao Yu wrote: >>>> On 2019/9/9 9:25, Jaegeuk Kim wrote: >>>>> GC must avoid select the same victim again. >>>> >>>> Blocks in previous victim will occupy addition free segment, I doubt after this >>>> change, FGGC may encounter out-of-free space issue more frequently. >>> >>> Hmm, actually this change seems wrong by sec_usage_check(). >>> We may be able to avoid this only in the suspicious loop? >>> >>> --- >>> 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 e88f98ddf396..5877bd729689 100644 >>> --- a/fs/f2fs/gc.c >>> +++ b/fs/f2fs/gc.c >>> @@ -1326,7 +1326,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync, >>> round++; >>> } >>> >>> - if (gc_type == FG_GC) >>> + if (gc_type == FG_GC && seg_freed) >> >> That's original solution Sahitya provided to avoid infinite loop of GC, but I >> suggest to find the root cause first, then we added .invalid_segmap for that >> purpose. > > I've checked the Sahitya's patch. So, it seems the problem can happen due to > is_alive or atomic_file. For some conditions, this doesn't help, for example, two sections contain the same fewest valid blocks, it will cause to loop selecting them if it fails to migrate blocks. How about keeping it as it is to find potential bug. Thanks, > >> >> Thanks, >> >>> sbi->cur_victim_sec = NULL_SEGNO; >>> >>> if (sync) >>> > . > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel