[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231129131315.GB12957@cuiyangpei>
Date: Wed, 29 Nov 2023 21:13:15 +0800
From: cuiyangpei <cuiyangpei@...il.com>
To: SeongJae Park <sj@...nel.org>, akpm@...ux-foundation.org,
damon@...ts.linux.dev, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Cc: xiongping1@...omi.com
Subject: Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
Hi SeongJae,
We are using damon on the Android operating system. It starts monitoring
when app comes to the foreground, stops monitoring and save the
monitoring results when app goes to the background.
The two methods that you mentioned,
1.tracepoint events
This method requires opening the tracepoint event and using the
'perf-record' tool to generate the perf.data file. Then parsing the
perf.data file. However, the user's phone is not enabled tracepoint
events. Additionally, the generated file is quite complex, and we only
need memory addresses and access frequency informations.
2. damos
There is no direct Python runtime environment on android phones.
Both of these methods provide results that are not very intuitive and
require complex parsing. We save the results in the format of starting
address, region size, and access frequency. When the available memory
reaches a threshold, the user space reclaim memory with low access
frequency by calling 'process_madvise' function.
Thanks.
On Tue, Nov 28, 2023 at 06:57:39PM +0000, SeongJae Park wrote:
> Hi Cuiyanpei,
>
>
> Thank you for this nice patchset.
>
> On Tue, 28 Nov 2023 15:34:39 +0800 cuiyangpei <cuiyangpei@...il.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@...omi.com>
Powered by blists - more mailing lists