linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Xin Hao <xhao@linux.alibaba.com>
Cc: SeongJae Park <sj@kernel.org>,
	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	[thread overview]
Message-ID: <20211022094341.3966-1-sj@kernel.org> (raw)
In-Reply-To: <a23c6f23-cf6b-1833-5603-363c45df933f@linux.alibaba.com>

On Fri, 22 Oct 2021 10:43:22 +0800 Xin Hao <xhao@linux.alibaba.com> wrote:

> 
> On 2021/10/22 上午1:30, SeongJae Park wrote:
> > Hello Xin,
> >
> > On Fri, 22 Oct 2021 00:44:16 +0800 Xin Hao <xhao@linux.alibaba.com> wrote:
> >
> >> 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 case are
> > quite simple ones, and therefore not supposed to incur viewable overhead.
> > After all, this is not a performance critical path.
> 
> Thank you for your detailed explanation. I may not describe it clearly, 
> making you think that i am making this
> 
> modification to improve performance,I just want to avoid irrelevant code 
> execution, thank you so much.

I guess I didn't make my point clear enough, sorry.  My concern in this patch
is the fact that it is adding more code.  IMHO, as the code is already working
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

[...]


      reply	other threads:[~2021-10-22  9:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-21 16:44 Xin Hao
2021-10-21 17:30 ` SeongJae Park
2021-10-22  2:43   ` Xin Hao
2021-10-22  9:43     ` SeongJae Park [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211022094341.3966-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sjpark@amazon.de \
    --cc=xhao@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox