Received: by 10.223.176.5 with SMTP id f5csp2622397wra; Mon, 29 Jan 2018 01:02:33 -0800 (PST) X-Google-Smtp-Source: AH8x225eC8nH28dkCoXVX6TIMGO6a+vMp1pmiVrQjOAlsqtoL0waDTlMLDmBWfRwSweamL0YRJdM X-Received: by 2002:a17:902:7789:: with SMTP id o9-v6mr1197384pll.84.1517216553682; Mon, 29 Jan 2018 01:02:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517216553; cv=none; d=google.com; s=arc-20160816; b=E2DPeABtTwIYCpEcKlmzxjxxND6HRsGRjtNRr6dNtVJPaW1ishod2fr4kkUPviqFxr IMZPlytuEMTy0hCojreDiuF/+8KGo1CwFyuYfGcRBF2qNQcAoCYKEiw/yVBedyuXhH43 Zn14ybzd4LsSsBsdgCysqqRFeyHU6nXMd1Zj/MSVt18Pt+sqqHumIJLh1adYqeN2PnQP KY2VEZUc85K7+zzl1dHqSP/0zd5A3a0OZSD4LFVUcKW1PUVtlIwRyGyrSy7CSyi3V3St CQF+eCPfRvw3FvzDUYhw12jJwmW3UlqEUa3tbG22YOi3sh9Rolf+DgbR3kApLfzaxYHE Pyyg== 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=rWqrUy+1Kg5qoV6CDfWjdD2m2sNf2OFfuxJgmC+80/0=; b=0DcA0dD7MvLJ2+oLCIqn56x/UBl8kVq1Ggf8GarUlUeta1B/wHhWBGkRJ5vm5xd8H3 vVLtA/Gnsx6UJA0f2F/OL3WkGSoSzoQVAAzxn5yCt7kqUSCJVzR+T8iHxUIHr9gnvEha 0q1eNi1ajT+ydD/c+Jj1xgw6btKL3lEeOlTaO1Ao3nrMszEV6rJHHJTXY19zaZaisDuy PiCKyFRusVTaPYUcH5bCkDMn8KfLGNCzCcslT78zoJh+BF4PMWRWvxKuCM/wWqJox+ga ZUzNlst9FEYuF3Tz+kl8xUa4un3CnPrf4tucUNdyGjbXxfP78TKTnHQfJLCueO34wz91 cK2Q== 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 k24-v6si665270pll.695.2018.01.29.01.01.54; Mon, 29 Jan 2018 01:02:33 -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 S1751573AbeA2JBa (ORCPT + 99 others); Mon, 29 Jan 2018 04:01:30 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:54492 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751127AbeA2JB2 (ORCPT ); Mon, 29 Jan 2018 04:01:28 -0500 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 5A861A81E50DF; Mon, 29 Jan 2018 17:01:14 +0800 (CST) Received: from [127.0.0.1] (10.134.22.195) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.361.1; Mon, 29 Jan 2018 17:01:05 +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> <607de57c-f5d8-2f22-b79d-4966a8516d1e@huawei.com> From: Chao Yu Message-ID: Date: Mon, 29 Jan 2018 17:01:04 +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: <607de57c-f5d8-2f22-b79d-4966a8516d1e@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 On 2018/1/29 16:31, Yunlong Song wrote: > The old commit allocates hot data & nodes in the beginning of partition > both for heap and > noheap mode. But from the commit message, the heap mode should be like > before, i.e., > allocate hot data & nodes from curseg to left. Let's ping Jaegeuk to check that, :) Thanks, > > On 2018/1/29 16:12, Chao Yu wrote: >> 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]) >>> >> >> . >> >