From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A735BC433EF for ; Fri, 22 Oct 2021 09:43:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 50B5A61205 for ; Fri, 22 Oct 2021 09:43:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 50B5A61205 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id CD7F2900003; Fri, 22 Oct 2021 05:43:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C60AF900002; Fri, 22 Oct 2021 05:43:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B286A900003; Fri, 22 Oct 2021 05:43:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0123.hostedemail.com [216.40.44.123]) by kanga.kvack.org (Postfix) with ESMTP id A424A900002 for ; Fri, 22 Oct 2021 05:43:47 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 67D7126815 for ; Fri, 22 Oct 2021 09:43:47 +0000 (UTC) X-FDA: 78723586494.20.94094B3 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf11.hostedemail.com (Postfix) with ESMTP id 11242F0000BA for ; Fri, 22 Oct 2021 09:43:46 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id A737B610EA; Fri, 22 Oct 2021 09:43:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1634895826; bh=dReKDaKJwqW3Io2bve4J9VXECU2Jr66ov+QZ5vpHXXE=; h=From:To:Cc:Subject:Date:In-Reply-To:From; b=TAzoAt/+5wohwJmdHC32vbbltcslPkFnm0pw8jVFs8mGVLs0IRWuz5/AZMR+PAJlm r+WgFzNJ1bvzBWZw3i0xydoJrXpqN0F8Md7NqXQHiyyztIqEHw7I+0MgjbAdyhuZEA 58uzEIFDBVZ2MaxhK79HgArwGhRkZ793G/Ll5NqsW+lZD0DdiAWaAgI7nXvGoynXW6 GPADNCSOcAd2rnfcPZ2jWSjEocw3dnzbfgzaL86f7Efty6m5fx4807i586B8n7KHrA +3o0KT1CN9li14SArDyMGMRqkKlAv/o+jCjxmmHthKPVVdRq+z0e2T36IuVWkHMjo0 Se1J5PFvctiEg== From: SeongJae Park To: Xin Hao Cc: SeongJae Park , sjpark@amazon.de, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V2] mm/damon/dbgfs: Optimize target_ids interface write operation Date: Fri, 22 Oct 2021 09:43:41 +0000 Message-Id: <20211022094341.3966-1-sj@kernel.org> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 X-Stat-Signature: ybyoqdyoigxx3mjjy6kq8xmhh8d4njpb X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 11242F0000BA Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="TAzoAt/+"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf11.hostedemail.com: domain of sj@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=sj@kernel.org X-HE-Tag: 1634895826-271540 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 22 Oct 2021 10:43:22 +0800 Xin Hao wrote= : >=20 > On 2021/10/22 =E4=B8=8A=E5=8D=881:30, SeongJae Park wrote: > > Hello Xin, > > > > On Fri, 22 Oct 2021 00:44:16 +0800 Xin Hao w= rote: > > > >> When we want to clear previously set target ids, > >> For example, it works as below now: > >> # echo 42 > target_ids > >> # cat target_ids > >> 42 > >> # echo > target_ids > >> # cat target_ids > >> > >> But in 'dbgfs_target_ids_write', there is no need to > >> execute other codes, except call 'damon_set_targets' > >> to clear previously set target ids. So there adds > >> the 'nr_targets' judgment, if the value is 0, just > >> call 'damon_set_targets', and then return. > > It's true that it executes some unnecessary code. However, I unsure = if that is > > a problem, as the code that will be additionally executed in this cas= e are > > quite simple ones, and therefore not supposed to incur viewable overh= ead. > > After all, this is not a performance critical path. >=20 > Thank you for your detailed explanation. I may not describe it clearly,= =20 > making you think that i am making this >=20 > modification to improve performance=EF=BC=8CI just want to avoid irrele= vant code=20 > execution, thank you so much. I guess I didn't make my point clear enough, sorry. My concern in this p= atch is the fact that it is adding more code. IMHO, as the code is already wo= rking correctly and benefit of this change is quite subtle as you also agreed, = adding the code here doesn't seem worthy but only making it harder to maintain, = to me. If I'm missing something, please let me know. Thanks, SJ [...]