Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3603669imu; Tue, 18 Dec 2018 00:50:22 -0800 (PST) X-Google-Smtp-Source: AFSGD/Vfiozgkpf994LfZLkBGJGI30rMyVL1OO4dtdu8uy07Wm3E3RXzaSwnIE7GCxxoBw8CrdxS X-Received: by 2002:a17:902:bb98:: with SMTP id m24mr15230169pls.71.1545123022755; Tue, 18 Dec 2018 00:50:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545123022; cv=none; d=google.com; s=arc-20160816; b=wlBMLePZn2dytqxRDUCUe9SRTLcVcR+JgRDr5FOhrw2HXASdFGh1azlASliYtWQtJ8 Zvt2vw8qUBzyM7tbhwK6FbNp+dKKvjkuuNsU60yKoop7z8w190rTB+vJtFSxHdyVGHRR Xddn2kIwaes6zRSyZgEtofhDHsFRJ8SKoMMPJ6dG/m92an+IgFvd+oRXofomf0WoR0tB vFkI9en+4TmVeKMLQSBupwr8hy3JLZAR+C6sNWwIV90+sblikDofWvZQpUL5XpUoI88g MSy1LdX3W2l8g3lJddzUCPAmnLPqWMbbxybgyGU0TxR2dlPRv1NsSjos2iitqo1Qb0Kp EWWg== 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:to:subject; bh=1oxcCbdhnqz6Ce/BADG60DgHYAHzdDjvb3DjGr8lvsA=; b=iT+w03RPBSM8OdNzggjOddVNytGzsmbE1+QqWk0jxwE8Mlwo9G1SERWwbNQhqXlWml psr7/T3dva3NsRMTzR48ujNyOml8DXXqQH6TnEKFgHT8gGyD2TYZHLRiNrhRPMdWLZn8 Jpf/Ud5lP6wJjuY+9J3Z5B+4DByYOtFJSpPpjlLg6DCqMFKpZF6Dm8YTsCq9zB2eZRz4 htto9B0x1kqY7GKRQcZGIPVTTFuAqT5RnzSaGWNDxbiQBcsmk1qkQmZFFiojMTjGWZbF wyswYfJj7xzVWj/mL6kUNu6+oJhrAWXWCpKBNYcyzm38dMyu+d6Od9eemLejrpfP+qRG cp9w== 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 i90si13811335pli.135.2018.12.18.00.50.07; Tue, 18 Dec 2018 00:50:22 -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 S1726452AbeLRItN (ORCPT + 99 others); Tue, 18 Dec 2018 03:49:13 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:16149 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726316AbeLRItM (ORCPT ); Tue, 18 Dec 2018 03:49:12 -0500 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 04226EBF28B95; Tue, 18 Dec 2018 16:49:08 +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.408.0; Tue, 18 Dec 2018 16:49:08 +0800 Subject: Re: [f2fs-dev] [PATCH 3/3] f2fs: flush stale issued discard candidates To: Jaegeuk Kim , , References: <20181214050127.45025-1-jaegeuk@kernel.org> <20181214050127.45025-3-jaegeuk@kernel.org> From: Chao Yu Message-ID: <639940cc-f7a8-e679-3b28-3b3b2485652b@huawei.com> Date: Tue, 18 Dec 2018 16:49:07 +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: <20181214050127.45025-3-jaegeuk@kernel.org> 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/12/14 13:01, Jaegeuk Kim wrote: > Sometimes, I could observe # of issuing_discard to be 1 which blocks background > jobs due to is_idle()=false. > The only way to get out of it was to trigger gc_urgent. This patch avoids that > by checking any candidates as done in the list. Well, as below code, once we issued discard commands, we will wait all queued discard end their IO, so do you know what flow can cause such condition...? issued = __issue_discard_cmd(sbi, &dpolicy); if (issued > 0) { __wait_all_discard_cmd(sbi, &dpolicy); Or, I doubt that 'issued' statistical info could be wrong. Thanks, > > Signed-off-by: Jaegeuk Kim > --- > fs/f2fs/segment.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c > index 49ea9009ab5a..acbbc924e518 100644 > --- a/fs/f2fs/segment.c > +++ b/fs/f2fs/segment.c > @@ -1651,6 +1651,10 @@ static int issue_discard_thread(void *data) > if (dcc->discard_wake) > dcc->discard_wake = 0; > > + /* clean up pending candidates before going to sleep */ > + if (atomic_read(&dcc->queued_discard)) > + __wait_all_discard_cmd(sbi, NULL); > + > if (try_to_freeze()) > continue; > if (f2fs_readonly(sbi->sb)) >