Received: by 10.223.176.5 with SMTP id f5csp2584363wra; Mon, 29 Jan 2018 00:13:35 -0800 (PST) X-Google-Smtp-Source: AH8x224vWpI/SIKR7w1FwJ/NpX+GcT/yVcLNwZY4psewxY1xCmgIPCHbRXvD7CO9n8CSH2KeHxtj X-Received: by 2002:a17:902:930c:: with SMTP id bc12-v6mr21456836plb.328.1517213615842; Mon, 29 Jan 2018 00:13:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517213615; cv=none; d=google.com; s=arc-20160816; b=TnxwT2c9niPbzDB8X2DC9LLR86lkGyJWkazEiFMfXtY4L5g6YKdpjgjYmW5QYg2IjP on00vohVBEt2mil7jclUC8y34xCTeHCD4waYIY0Mre6oKjsq7enkNjwFphXrNgo9pr22 dbWhAh0nIBGPLsTWCo45C0kibnBnW+dyNdfg7y/ENvrkpf1WokXb0eSHYk+KKyBtnJgy ZfhsPPs4tSOoTiumMEYEuLy/8qc8hnk4Bhg2xeA3M5cErtyyUPdOXqMuTVi1q5Q++IfX SepfXC2r5KJc2h/cdkKJGRUJptjDMnnBCGCgmQ8DTCciQMzg6totdfnbAZFsOdEjxOdF XWRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=1EYt7lmPk6nXAF8qAjEk9wqD1JHGg7OHBeK82cDL/vM=; b=OyoJ6ApTQ6a3RokujgMWmf7p7viIhGb0skNoe5GNII5m5PntY8tL+XgF6WbibSp91J ytwukyDkvrTJUXHEQnK1cNr22qTZIKeqm7+1V064rlE9F0w+RpKcQ+rGGWC70toLH0fR lWYALly5vlCLUXG4M4lE1XJa7AFbQf1xUen3o7zyMzGhcQwhTIKYCzKXZKWxgLHSms3y l8LCKhNZtWhk8PZRo2ZIHXCJIh2M7UADAqYh1IKNE1eCt10l/D4ODNVy6wjzpP+tn7ij Ks+t2W8EzHYgqSQatdPEInpm9WR5IGeIjZwt6L8AHjdpeb90YJ8DfqY/DdCkU2tUmOEk fUMg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u17-v6si2887513plj.646.2018.01.29.00.13.21; Mon, 29 Jan 2018 00:13:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751516AbeA2IMs (ORCPT + 99 others); Mon, 29 Jan 2018 03:12:48 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:4710 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751127AbeA2IMq (ORCPT ); Mon, 29 Jan 2018 03:12:46 -0500 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id B09811E6FB1AE; Mon, 29 Jan 2018 16:12:31 +0800 (CST) Received: from [127.0.0.1] (10.134.22.195) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.361.1; Mon, 29 Jan 2018 16:12:22 +0800 Subject: Re: [PATCH] f2fs: fix heap mode to reset it back To: Yunlong Song , , , CC: , , , , , , References: <1517197065-156255-1-git-send-email-yunlong.song@huawei.com> From: Chao Yu Message-ID: Date: Mon, 29 Jan 2018 16:12:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1517197065-156255-1-git-send-email-yunlong.song@huawei.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 Hi Yunlong, On 2018/1/29 11:37, Yunlong Song wrote: > Commit 7a20b8a61eff81bdb7097a578752a74860e9d142 ("f2fs: allocate node > and hot data in the beginning of partition") introduces another mount > option, heap, to reset it back. But it does not do anything for heap > mode, so fix it. I think Jaegeuk did three things in that patch: a) add missing heap mount option handling in ->show_options. b) set noheap by default. c) change allocation policy to the one that allocate hotdata & nodes in the front of main are intensively. They could be separated, independent, and I don't see such intention that we can only use c) the new introduced allocation policy in noheap mode. Anyway, I think Jaegeuk can help to double check that. Thanks, > > Signed-off-by: Yunlong Song > --- > fs/f2fs/gc.c | 5 +++-- > fs/f2fs/segment.c | 3 ++- > 2 files changed, 5 insertions(+), 3 deletions(-) > > diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c > index aa720cc..b9d93fd 100644 > --- a/fs/f2fs/gc.c > +++ b/fs/f2fs/gc.c > @@ -191,8 +191,9 @@ static void select_policy(struct f2fs_sb_info *sbi, int gc_type, > if (gc_type != FG_GC && p->max_search > sbi->max_victim_search) > p->max_search = sbi->max_victim_search; > > - /* let's select beginning hot/small space first */ > - if (type == CURSEG_HOT_DATA || IS_NODESEG(type)) > + /* let's select beginning hot/small space first in no_heap mode*/ > + if (test_opt(sbi, NOHEAP) && > + (type == CURSEG_HOT_DATA || IS_NODESEG(type))) > p->offset = 0; > else > p->offset = SIT_I(sbi)->last_victim[p->gc_mode]; > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c > index e5739ce..77a48c4 100644 > --- a/fs/f2fs/segment.c > +++ b/fs/f2fs/segment.c > @@ -2167,7 +2167,8 @@ static unsigned int __get_next_segno(struct f2fs_sb_info *sbi, int type) > if (sbi->segs_per_sec != 1) > return CURSEG_I(sbi, type)->segno; > > - if (type == CURSEG_HOT_DATA || IS_NODESEG(type)) > + if (test_opt(sbi, NOHEAP) && > + (type == CURSEG_HOT_DATA || IS_NODESEG(type))) > return 0; > > if (SIT_I(sbi)->last_victim[ALLOC_NEXT]) >