From patchwork Thu Feb 23 00:59:15 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jaegeuk Kim X-Patchwork-Id: 9587635 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 7355A60578 for ; Thu, 23 Feb 2017 01:26:15 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 62C5B2860C for ; Thu, 23 Feb 2017 01:26:15 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 576A928670; Thu, 23 Feb 2017 01:26:15 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 03AEB2860C for ; Thu, 23 Feb 2017 01:26:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934381AbdBWB0N (ORCPT ); Wed, 22 Feb 2017 20:26:13 -0500 Received: from mail.kernel.org ([198.145.29.136]:52796 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933325AbdBWB0N (ORCPT ); Wed, 22 Feb 2017 20:26:13 -0500 Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5667620154; Thu, 23 Feb 2017 00:59:17 +0000 (UTC) Received: from localhost (107-1-141-74-ip-static.hfc.comcastbusiness.net [107.1.141.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 41D312012D; Thu, 23 Feb 2017 00:59:16 +0000 (UTC) Date: Wed, 22 Feb 2017 16:59:15 -0800 From: Jaegeuk Kim To: Yunlong Song Cc: cm224.lee@samsung.com, yuchao0@huawei.com, chao@kernel.org, sylinux@163.com, miaoxie@huawei.com, bintian.wang@huawei.com, linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] f2fs: clean up codes in get_ssr_segment Message-ID: <20170223005915.GG4003@jaegeuk.local> References: <1487767851-819-1-git-send-email-yunlong.song@huawei.com> <20170223004114.GF4003@jaegeuk.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170223004114.GF4003@jaegeuk.local> User-Agent: Mutt/1.7.0 (2016-08-17) X-Virus-Scanned: ClamAV using ClamSMTP Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 02/22, Jaegeuk Kim wrote: > Hi Yunlong, > > This is NOT clean-up. What's your point here? I guess you wanted to do like this. From 8d344ac45890dd95c5734fd29a19a7c19364c327 Mon Sep 17 00:00:00 2001 From: Yunlong Song Date: Wed, 22 Feb 2017 20:50:49 +0800 Subject: [PATCH] f2fs: do SSR for data when there is enough free space In allocate_segment_by_default(), need_SSR() already detected it's time to do SSR. So, let's try to find victims for data segments more aggressively in time. Signed-off-by: Yunlong Song Signed-off-by: Jaegeuk Kim --- fs/f2fs/segment.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index d01ee7b94702..c27dab43c42f 100644 --- a/fs/f2fs/segment.c +++ b/fs/f2fs/segment.c @@ -1541,7 +1541,7 @@ static int get_ssr_segment(struct f2fs_sb_info *sbi, int type) struct curseg_info *curseg = CURSEG_I(sbi, type); const struct victim_selection *v_ops = DIRTY_I(sbi)->v_ops; - if (IS_NODESEG(type) || !has_not_enough_free_secs(sbi, 0, 0)) + if (IS_NODESEG(type)) return v_ops->get_victim(sbi, &(curseg)->next_segno, BG_GC, type, SSR);