From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753597AbeDISCn (ORCPT ); Mon, 9 Apr 2018 14:02:43 -0400 Received: from mail.kernel.org ([198.145.29.99]:39934 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751728AbeDISCm (ORCPT ); Mon, 9 Apr 2018 14:02:42 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1F91C21771 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=jaegeuk@kernel.org Date: Mon, 9 Apr 2018 11:02:41 -0700 From: Jaegeuk Kim To: Chao Yu Cc: linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, chao@kernel.org Subject: Re: [PATCH] f2fs: enlarge block plug coverage Message-ID: <20180409180241.GC17558@jaegeuk-macbookpro.roam.corp.google.com> References: <20180404085404.82184-1-yuchao0@huawei.com> <20180405035115.GC50337@jaegeuk-macbookpro.roam.corp.google.com> <03c21c2f-cb0e-dbd4-b48a-95c2678964d1@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03c21c2f-cb0e-dbd4-b48a-95c2678964d1@huawei.com> User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/08, Chao Yu wrote: > On 2018/4/5 11:51, Jaegeuk Kim wrote: > > On 04/04, Chao Yu wrote: > >> This patch enlarges block plug coverage in __issue_discard_cmd, in > >> order to collect more pending bios before issuing them, to avoid > >> being disturbed by previous discard I/O in IO aware discard mode. > > > > Hmm, then we need to wait for huge discard IO for over 10 secs, which > > We found that total discard latency is rely on total discard number we issued > last time instead of range or length discard covered. IMO, if we don't change > .max_requests value, we will not suffer longer latency. > > > will affect following read/write IOs accordingly. In order to avoid that, > > we actually need to limit the discard size. > > If you are worry about I/O interference in between discard and rw, I suggest to > decrease .max_requests value. What do you mean? This will produce more pending requests in the queue? > > Thanks, > > > > > Thanks, > > > >> > >> Signed-off-by: Chao Yu > >> --- > >> fs/f2fs/segment.c | 7 +++++-- > >> 1 file changed, 5 insertions(+), 2 deletions(-) > >> > >> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c > >> index 8f0b5ba46315..4287e208c040 100644 > >> --- a/fs/f2fs/segment.c > >> +++ b/fs/f2fs/segment.c > >> @@ -1208,10 +1208,12 @@ static int __issue_discard_cmd(struct f2fs_sb_info *sbi, > >> pend_list = &dcc->pend_list[i]; > >> > >> mutex_lock(&dcc->cmd_lock); > >> + > >> + blk_start_plug(&plug); > >> + > >> if (list_empty(pend_list)) > >> goto next; > >> f2fs_bug_on(sbi, !__check_rb_tree_consistence(sbi, &dcc->root)); > >> - blk_start_plug(&plug); > >> list_for_each_entry_safe(dc, tmp, pend_list, list) { > >> f2fs_bug_on(sbi, dc->state != D_PREP); > >> > >> @@ -1227,8 +1229,9 @@ static int __issue_discard_cmd(struct f2fs_sb_info *sbi, > >> if (++iter >= dpolicy->max_requests) > >> break; > >> } > >> - blk_finish_plug(&plug); > >> next: > >> + blk_finish_plug(&plug); > >> + > >> mutex_unlock(&dcc->cmd_lock); > >> > >> if (iter >= dpolicy->max_requests) > >> -- > >> 2.15.0.55.gc2ece9dc4de6 > > > > . > >