Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752051AbdIMIsh (ORCPT ); Wed, 13 Sep 2017 04:48:37 -0400 Received: from mailout1.samsung.com ([203.254.224.24]:37827 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751913AbdIMIsd (ORCPT ); Wed, 13 Sep 2017 04:48:33 -0400 X-AuditID: b6c32a36-f79196d0000051db-6e-59b8f0de37b4 Mime-Version: 1.0 Subject: Re: [f2fs-dev] [PATCH] f2fs: fix double count on issued discard commands Reply-To: daeho.jeong@samsung.com From: Daeho Jeong To: "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-f2fs-devel@lists.sourceforge.net" X-Priority: 3 X-Content-Kind-Code: NORMAL In-Reply-To: X-Drm-Type: N,general X-EPLocale: ko_KR.EUC-KR X-EPWebmail-Msg-Type: personal X-Msg-Generator: Mail X-Msg-Type: PERSONAL X-Reply-Demand: N Illegal-Object: Syntax error in X-Sender: address found on vger.kernel.org: X-Sender: =?utf-8?B?U2Ftc3VuZyBFbGVjdHJvbmljcxtTeXN0ZW0gUy8=?= ^-Extraneous program text X-Sender-IP: 10.253.99.247 X-Local-Sender: =?UTF-8?B?7KCV64yA7Zi4G1N5c3RlbSBTL1fqsJzrsJwx6re466O5KOustOyEoCkb?= =?UTF-8?B?7IK87ISx7KCE7J6QG1NlbmlvciBFbmdpbmVlci9FeHBlcnQg?= =?UTF-8?B?UHJvZ3JhbW1lcg==?= X-Global-Sender: =?UTF-8?B?RGFlaG8gSmVvbmcbU3lzdGVtIFMvVyBSJkQgR3JvdXAgMRtTYW1zdW5n?= =?UTF-8?B?IEVsZWN0cm9uaWNzG1NlbmlvciBFbmdpbmVlcg==?= X-Sender-Code: =?UTF-8?B?QzEwGxtDMTBEOTEyMQ==?= Message-ID: <20170913084830epcms1p8a0a01f9de4c8f09730206203b9969a79@epcms1p8> Date: Wed, 13 Sep 2017 08:48:30 +0000 X-CMS-MailID: 20170913084830epcms1p8a0a01f9de4c8f09730206203b9969a79 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-ArchiveUser: EV X-MTR: 20170913084830epcms1p8a0a01f9de4c8f09730206203b9969a79 CMS-TYPE: 101P X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDJsWRmVeSWpSXmKPExsWy7bCmru79DzsiDZadYrLY82kdm8WlRe4W e/aeZLG4vGsOmwOLx+4Fn5k8+rasYvT4vEkugDmqgdEmsSg5I7MsVSE1Lzk/JTMv3VYpNMRN 10JJISO/uMRWKdrIwFjPyNREz8jEXM/SINbKyFRJIS8xN9VWqUIXqldJoSi5AKg2t7IYaEBO qh5UXK84NS/FISu/FORCveLE3OLSvHS95PxcJYWyxJxSoBFK+gkfGDNWNzxjL5jPXtF18hNL A+MN1i5GDg4JAROJFZdiuxg5gUwxiQv31rN1MXJxCAnsYJTobbnADFLDKyAo8XeHMIgpLBAs 8f+5C0i5kICixKq/nWwgtrCArsSSKUdYQGw2AW2J6ctnsYOMERG4zSixdfoUVoj5vBIz2p+y QNjSEtuXb2UEsTkF7CSmrpwEFReVuLn6LTuELSFx5/UFJghbTmLa1zXMMDXvj81nhLBFJFrv nYWKC0o8+LkbKl4q8ezsRag5UhK3n5xig7A3MUpcXMsKcpyEQA+jxOON66EW6Esc2HAHrIhX wFfiyeJvbCAPswioSvy+ZwZR4iKx+s8qsDuZBeQltr+dAw4eZgFNifW79GFOOH2tmxkSsrYS +7dnQVTzSbz72gMNBVWJVT8WME9gVJmFCNtZSGbOQpi5gJF5FaNYakFxbnpqsWGBEXLkbmIE p0Utsx2Mi875HGIU4GBU4uENuLU9Uog1say4MvcQowQHs5IIr+S7HZFCvCmJlVWpRfnxRaU5 qcWHGJOBPpvILCWanA9M2Xkl8YYmlgYmZkampoYGFibIwsYGBkaGBubmlubGOISVxHlF11+L EBJITyxJzU5NLUgtgtnCxMEp1cC4v0TM8zyvWbXDr+W3+TusPHhvTYydfGGHmuQbi4igwCaB By+bNk5fbHHCJkW1Nvyx0pQd73Z8WeJ3O5wr7PWGfGkvjp97HHMffPpbrvf0F2tayXbZkuj9 0+JKX36V1FjdtozbnO2JE8/+3bdzAo9FL6x5d/NtVaTTyWq/Y29OHArnfWr5THifEktxRqKh FnNRcSIAJy1bpM8DAAA= DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20170912042935epcas1p4630737028cc7b9536a0c688c92084e84 X-RootMTR: 20170912042935epcas1p4630737028cc7b9536a0c688c92084e84 References: <20170912042916.GA95671@jaegeuk-macbookpro.roam.corp.google.com> <20170911033845.53701-1-jaegeuk@kernel.org> <6209aa5a-4d45-ac2b-448a-4b405dfb25d1@huawei.com> <20170912043423epcms1p72de7da42985bf53e94e50ea8474b682c@epcms1p7> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 906 Lines: 21 > Actually, we didn't change priority of discard command, so that it is still > synchronous IO for I/O scheduler, hence I/O interference will still exist if we > try to issue discard without IO aware ability. > Of course we can change the priority of discard command to lower, but potential > issue is that with ROW I/O scheduler in kernel or FTL, async I/O will handle > very slowly in heavy load scenario, if we are going to trigger sync write IO in > place in where we're doing async discard, we will face long latency. > Still I think it is worth to build the ability to issue async discard as a part > of discard policy and later we can adjust policy based on different scenario. > Thanks, Oh, I see. f2fs is sending discard requests as "sync" requests, I didn't know that. Right, I just though in case of CFQ I/O scheduler, but f2fs has to consider the other schedulers, but CFQ. Thanks, :)