Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp7648694rwb; Mon, 12 Dec 2022 18:25:12 -0800 (PST) X-Google-Smtp-Source: AA0mqf5+xbDfiYN13wSeCDeYyVbWnviksjJOyKrB0mV72bYGNugMlS0pb8JWBqC07pTwx+93d798 X-Received: by 2002:a05:6402:2992:b0:461:ed1f:e707 with SMTP id eq18-20020a056402299200b00461ed1fe707mr15742801edb.17.1670898312688; Mon, 12 Dec 2022 18:25:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670898312; cv=none; d=google.com; s=arc-20160816; b=gzUSEpxPXr2cBA9gWWNkjZnK09xUgzqiF1DuT0/fuPyaA3GWsJMIOTF1mkf3z9GjoM ldzvDVdKClve3pkJqnFH3ImzLNZs5fscL9QqazkxVa1Odoz8Bka+8LVzk+Y5WokeB70I 7ngms6Nl+AktqGZPlulpVRUzpI8NaMBs4fgCLEmpmuIILGu5g8TcaQIfBqLpAzoe9/lO nyFrgDLViyZJcXgzR1Rp8yuaj3ve3s0DNF4IHZ1zd68gPGRyB0PbeCwgSvpuNmt5Nu1s fKWevQSrt9fibC64Lm5lvn9/zEGbJNXBkKB/x3WtdW6rTeORoMr6o0DmbzaOUy91XLBk cPNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=VdlYKClYg0wJEaflRx6HXXOWyCZS+RcahXunHnfze/c=; b=E92wUu6NkA5LtpOiBrtoZEnsx1vBJbqiLU0XJ2y2Zj2+/xA/DOb/cPYsmvc2AI3quf CTydRbO6O8XIAbbgiAprwy74XqMeOULFoemTnejWnnIp+2C5HU4yvWz/pFbzFbvXoxzD lrnbe8BAScMZz+rvurS/+N6fidiJIRw+jJFLPKMQArzbP5iQvT8JhQ9gj4B7jJVDo4pz 3kIrmx3bxjAsqHQ7nVb19uRVUI7DGMSdrT1R0T7y+99j9jJ5fz/5kncJOT0IAOm85ZUY L4FxThOCxKqEQU8Gx8uGL3grdp8vUSwS8te+KjOxdLg+f2IrrjMvFi9/6a8YyvM96e1A VVWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=tCWz3ghv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h4-20020aa7c944000000b00468eee74e58si7643033edt.273.2022.12.12.18.24.54; Mon, 12 Dec 2022 18:25:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=tCWz3ghv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234194AbiLMBqu (ORCPT + 74 others); Mon, 12 Dec 2022 20:46:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32942 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233772AbiLMBqs (ORCPT ); Mon, 12 Dec 2022 20:46:48 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 806EB15FC9 for ; Mon, 12 Dec 2022 17:46:47 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 228216119B for ; Tue, 13 Dec 2022 01:46:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85C08C433EF; Tue, 13 Dec 2022 01:46:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670896006; bh=b492jcWSHExPhifU02diqtfeCSUJqNIU0MHaeSHNsgs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=tCWz3ghvT7KvybgeJgSPd5ymmNqE2Q2l7U6FpjpqZqjYFxSrln54n805iVzdfQ/Q9 NYsCvwvrXJNGunFUaXHbwUAKRMsxJ5KK0e4Bj4oMbuWTzIBaMuyo77Ujlcchi1ASjw /AvBW6vZhmt3K59u1fmGaEPE31GulLwOSE31u2Zo5RWs69LKBVwZh5Jxn3aU3oRBz9 TOz3cPPOSNTyGIno2TWpxINHSyEju9zL2u2+f7RWlhMIbU34VRI9JA9Y9WYxv+sDdK DUKpk67UhORQK41+dTa4s8ud5p43UpUOaiBszuslozDhGttUUIy/0Dl53eMRWusTCW oFscnuwbkruAg== Message-ID: Date: Tue, 13 Dec 2022 09:46:43 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH] f2fs: fix iostat parameter for discard Content-Language: en-US To: Jaegeuk Kim Cc: Yangtao Li , linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org References: <20221205145603.70779-1-frank.li@vivo.com> <38ab73c5-4865-188f-9554-6bcaec7cc78b@kernel.org> From: Chao Yu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/12/13 6:59, Jaegeuk Kim wrote: > On 12/11, Chao Yu wrote: >> On 2022/12/5 22:56, Yangtao Li wrote: >>> Just like other data we count uses the number of bytes as the basic unit, >>> but discard uses the number of cmds as the statistical unit. In fact the >>> discard command contains the number of blocks, so let's change to the >>> number of bytes as the base unit. >>> >>> Fixes: b0af6d491a6b ("f2fs: add app/fs io stat") >>> >>> Signed-off-by: Yangtao Li >>> --- >>> 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 9486ca49ecb1..bc262e17b279 100644 >>> --- a/fs/f2fs/segment.c >>> +++ b/fs/f2fs/segment.c >>> @@ -1181,7 +1181,7 @@ static int __submit_discard_cmd(struct f2fs_sb_info *sbi, >>> atomic_inc(&dcc->issued_discard); >>> - f2fs_update_iostat(sbi, NULL, FS_DISCARD, 1); >>> + f2fs_update_iostat(sbi, NULL, FS_DISCARD, len * F2FS_BLKSIZE); >> >> In order to avoid breaking its usage of application, how about keeping >> FS_DISCARD as it is, and add FS_DISCARD_IO to account discard bytes? > > I picked this to match the f2fs_update_iostat() definition. Do we know > how many applications will be affected? I don't have any at a glance in > Android tho. I guess there is some private scripts in OEM rely on this, and I don't see any non-Android users using this. > > void f2fs_update_iostat(struct f2fs_sb_info *sbi, struct inode *inode, > enum iostat_type type, unsigned long long io_bytes) What do you think of extending this function to support io_counts? void f2fs_update_iostat(struct f2fs_sb_info *sbi, struct inode *inode, enum iostat_type type, unsigned long long io_bytes, unsigned long long io_counts) Thanks, > > >> >> Thanks, >> >>> lstart += len; >>> start += len;