All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: cuiyangpei <cuiyangpei@gmail.com>
Cc: sj@kernel.org, akpm@linux-foundation.org, damon@lists.linux.dev,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	cuiyangpei <cuiyangpei@xiaomi.com>
Subject: Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
Date: Tue, 28 Nov 2023 18:57:39 +0000	[thread overview]
Message-ID: <20231128185739.47916-1-sj@kernel.org> (raw)
In-Reply-To: <20231128073440.11894-1-cuiyangpei@xiaomi.com>

Hi Cuiyanpei,


Thank you for this nice patchset.

On Tue, 28 Nov 2023 15:34:39 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:

> The user space users can control DAMON and get the monitoring results
> via implements 'recording' feature in 'damon-sysfs'.  The feature
> can be used via 'record' and 'state' file in the '<sysfs>/kernel/mm/
> damon/admin/kdamonds/N/' directory.
> 
> The file allows users to record monitored access patterns in a text
> file. Firstly, users set the size of the buffer and the path of the
> result file by writing to the ``record`` file. Then the recorded
> results are first written in an in-memory buffer and flushed the
> recorded results to a file in batch by writing 'record' to the
> ``state`` file.
> 
> For example, below commands set the buffer to be 4 KiB and the result
> to be saved in ``/damon.txt``. ::
> 
>     # cd <sysfs>/kernel/mm/damon/admin/kdamonds/N
>     # echo "4096 /damon.txt" > record
>     # echo "record" > state

This reminds me the record feature of DAMON debugfs interface[1], which still
not merged in the mainline.  I deprioritized the patchset to have a better
answer to Andrew's questions on the discussion (nice definition of the binary
format and quatization of the benefit), and later I realized I don't have real
use case that this makes real benefit, so I'm no more aiming to make this
merged into the mainline.

More specifically, I'm now thinking the feature is not really needed since
trace event based recording works, and we found no problem so far.  The DAMON
user-space tool (damo)[2] also dropped support of the in-kernel record feature,
but we received no problem report.

Also, I believe DAMOS tried regions like feature could provide some level of
information, since it provides snapshot of the monitoring result, which
contains a time data, namely 'age'.

Could you please further elaborate your aimed use case of this feature and the
advantage compared to other alternatives (tracepoint-based recording or DAMOS
tried regions based snapshot collecting) I mentioned above?

[1] https://lore.kernel.org/linux-mm/20211011093057.30790-1-sj@kernel.org/
[2] https://github.com/awslabs/damo


Thanks,
SJ

> 
> Signed-off-by: cuiyangpei <cuiyangpei@xiaomi.com>

  parent reply	other threads:[~2023-11-28 18:57 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-28  7:34 [PATCH 1/2] mm/damon/sysfs: Implement recording feature cuiyangpei
2023-11-28  7:34 ` [PATCH 2/2] mm/damon/core: add sysfs nodes to set last_nr_accesses weight cuiyangpei
2023-11-28 16:11 ` [PATCH 1/2] mm/damon/sysfs: Implement recording feature kernel test robot
2023-11-28 16:21 ` kernel test robot
2023-11-28 18:57 ` SeongJae Park [this message]
2023-11-29  7:58   ` Cui Yangpei
2023-11-29 13:13   ` cuiyangpei
2023-11-29 17:10     ` SeongJae Park
2023-11-30  9:14       ` cuiyangpei
2023-11-30 19:44         ` SeongJae Park
2023-12-01 12:25           ` cuiyangpei
2023-12-01 17:31             ` SeongJae Park
2023-12-03  5:43               ` cuiyangpei
2023-12-03 19:37                 ` SeongJae Park
2024-01-22  5:46                   ` cuiyangpei
2024-01-22 17:56                     ` SeongJae Park
2024-01-26  6:57                       ` cuiyangpei
2024-01-26  8:04                         ` SeongJae Park
2024-01-28  9:13                           ` cuiyangpei
2024-01-28 16:28                             ` SeongJae Park
2024-01-29 12:13                               ` cuiyangpei
2024-02-06  2:56                                 ` SeongJae Park
2024-02-06  3:26                                   ` cuiyangpei
2026-03-15 21:14             ` SeongJae Park

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=20231128185739.47916-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cuiyangpei@gmail.com \
    --cc=cuiyangpei@xiaomi.com \
    --cc=damon@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.