linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: cuiyangpei <cuiyangpei@gmail.com>
To: SeongJae Park <sj@kernel.org>,
	akpm@linux-foundation.org, damon@lists.linux.dev,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: xiongping1@xiaomi.com
Subject: Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
Date: Thu, 30 Nov 2023 17:14:26 +0800	[thread overview]
Message-ID: <20231130091426.GA13946@cuiyangpei> (raw)
In-Reply-To: <20231129171058.50270-1-sj@kernel.org>

Hi SeongJae,

We also investigated the operation schemes you mentioned, but we don't
think it can fit our needs.

On android, user will open many apps and switch between these apps as
needs. We hope to monitor apps' memory access only when they are on
foreground and record the memory access pattern when they are switched
to the background. 

When avaliable memory reaches a threshold, we will use these access
patterns with some strategies to recognize those memory that will have
little impact on user experience and to reclaim them proactively.  

I'm not sure I have clarified it clearly, if you still have questions
on this, please let us know.

Thanks.

On Wed, Nov 29, 2023 at 05:10:58PM +0000, SeongJae Park wrote:
> Hi Cuiyangpei,
> 
> On Wed, 29 Nov 2023 21:13:15 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> 
> > 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.
> 
> Thank you so much for sharing this detailed use case.  This will be very
> helpful for us at understanding real usage of DAMON and making it better for
> that together.
> 
> > 
> > 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.
> 
> That's fair points, thank you for kindly explaining this.
> 
> > 
> > 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.
> 
> Again, very fair points.  So, if I understood correctly, you want to reclaim
> cold pages proactively when the available memory reaches a threshold, right?
> DAMON could do that directly instead of you[1].  Using that, you don't need to
> save the access pattern and parse but just ask DAMON to find memory regions of
> specific access frequency range and reclaim.  Have you also considered using
> that but found some problems?
> 
> I understand the feature may not perfectly fit for your use case, and I want to
> learn from you how it could be better.
> 
> [1] https://docs.kernel.org/mm/damon/design.html#operation-schemes
> 
> 
> Thanks,
> SJ
> 
> > 
> > Thanks.
> > 
> [...]


  reply	other threads:[~2023-11-30  9:14 UTC|newest]

Thread overview: 23+ 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
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 [this message]
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

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=20231130091426.GA13946@cuiyangpei \
    --to=cuiyangpei@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=damon@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sj@kernel.org \
    --cc=xiongping1@xiaomi.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).