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 V1 2/2] mm/damon: Add 'age' of region tracepoint support
Date: Thu, 11 Nov 2021 08:20:34 +0000	[thread overview]
Message-ID: <20211111082034.13323-1-sj@kernel.org> (raw)
In-Reply-To: <d7edb182-7d49-712e-2d21-7b9f7ae2e4f1@linux.alibaba.com>

On Thu, 11 Nov 2021 10:04:38 +0800 Xin Hao <xhao@linux.alibaba.com> wrote:

> [-- Attachment #1: Type: text/plain, Size: 8070 bytes --]
> 
> Hi Park:
> 
> On 2021/11/10 下午9:16, SeongJae Park wrote:
> > On Wed, 10 Nov 2021 20:13:14 +0800 Xin Hao <xhao@linux.alibaba.com> wrote:
> >
> >> In patch "mm/damon: add a tracepoint", it adds a
> >> tracepoint for DAMON, it can monitor each region
> >> for each aggregation interval, Now the region add
> >> a new 'age' variable, some primitive would calculate
> >> the priority of each region as a weight, there put it
> >> into tracepoint, so we can easily track the change of
> >> its value through perf or damon-tools.
> > DAMON calculates the age using the address range and nr_accesses of the region,
> > which are already in the tracepoint.  In other words, user space can calculate
> > the age on their own.  Therefore I thought putting age in the tracepoint as
> > adding unnecessary information, at the moment of the implementation.
> >
> > Of course, I would missing some use cases that need this information in the
> > tracepoint.  Furthermore, adding just one more value in the tracepoint wouldn't
> > incur a real issue.  But, I'd like to know why this is necessary and how much
> > benefit it provides.  Xin, could you please share that?
> 
> I think these two variables nr_access &  age have different meanings, 
> the nr_access only reflect the
> 
> period of  sample_interval,  We may be able to get the change of age 
> through continuous long-term sampling,
> 
> But I think this is not very convenient.
> 
> We only need to observe the change of age value a small number of times 
> to replace the continue sampling of the region.
> 
> For example, age has been increasing to 141, but nr_access shows a value 
> of 0 at a certain time. Through this,we can
> 
> conclude that the region has a very low nr_access value for a long time.

I understand that you don't want to record all the traces and then process the
huge trace data in user space in order to get the age information, because you
want to save disk space and CPU cycles.  Is that correct?  If so, I think that
makes sense, and it would be better to put that in the commit message.


Thanks,
SJ

[...]


  reply	other threads:[~2021-11-11  8:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-10 12:13 [PATCH V1 0/2] mm/damon: Do some small changes Xin Hao
2021-11-10 12:13 ` [PATCH V1 1/2] mm/damon: Unified access_check function naming rules Xin Hao
2021-11-10 12:59   ` SeongJae Park
2021-11-10 12:13 ` [PATCH V1 2/2] mm/damon: Add 'age' of region tracepoint support Xin Hao
2021-11-10 13:16   ` SeongJae Park
2021-11-11  2:04     ` Xin Hao
2021-11-11  8:20       ` SeongJae Park [this message]
2021-11-11  8:29         ` Xin Hao

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=20211111082034.13323-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;
as well as URLs for NNTP newsgroup(s).