Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752476AbdILRMD (ORCPT ); Tue, 12 Sep 2017 13:12:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:34798 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751444AbdILRL6 (ORCPT ); Tue, 12 Sep 2017 13:11:58 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 95F3A2190B 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: Tue, 12 Sep 2017 10:11:57 -0700 From: Jaegeuk Kim To: Daeho Jeong Cc: "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-f2fs-devel@lists.sourceforge.net" Subject: Re: [f2fs-dev] [PATCH] f2fs: fix double count on issued discard commands Message-ID: <20170912171157.GA2597@jaegeuk-macbookpro.roam.corp.google.com> References: <20170912042916.GA95671@jaegeuk-macbookpro.roam.corp.google.com> <20170911033845.53701-1-jaegeuk@kernel.org> <6209aa5a-4d45-ac2b-448a-4b405dfb25d1@huawei.com> <20170912043423epcms1p72de7da42985bf53e94e50ea8474b682c@epcms1p7> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170912043423epcms1p72de7da42985bf53e94e50ea8474b682c@epcms1p7> 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 Content-Length: 1147 Lines: 27 On 09/12, Daeho Jeong wrote: > > Yeah,?that's?exactly?like?what?I?made?a?mistake?before. > > I?should?have?mentioned?that?earlier.?:) > > Or I think the previous code which used "iter++" might be right. > You might just want to check the fixed number of small discards, DISCARD_ISSUE_RATE, > when issue_cond is "true". > > Anyways, I have another question about this function. > How about just issuing, not checking whether it is idle, the fixed number of small > discards, DISCARD_ISSUE_RATE, when issue_cond is "true". > Actually, the discard commands will be issued as "asynchronous" requests, > which has a low priority in the I/O scheduler, > so the performance degradation of other threads by doing this will not be much severe, > but we can make the performance of the storage device better even if there is no idle. I don't think I/O scheduler can efficiently prioritize discard commands and user requests. The proper way that we can do would be waiting for idle time at this moment. Thanks, > > I am just worried about the storage device I/O performance gets worse > under I/O intensive senario where there is no idle > > Thanks,