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: Fri, 1 Dec 2023 20:25:07 +0800 [thread overview]
Message-ID: <20231201122507.GA15806@cuiyangpei> (raw)
In-Reply-To: <20231130194420.51355-1-sj@kernel.org>
On Thu, Nov 30, 2023 at 07:44:20PM +0000, SeongJae Park wrote:
> Hi Cuiyangpei,
>
> On Thu, 30 Nov 2023 17:14:26 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
>
> > 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.
>
> So, to my understanding, you expect applications may keep similar access
> pattern when they are in foreground, but have a different, less aggressive
> access pattern in background, and therefore reclaim memory based on the
> foreground-access pattern, right?
>
Different apps may have different access pattern. On android, the apps will
join in freeze cgroup and be frozen after switch to the background. So we
monitor apps' memory access only when they are in foreground.
> Very interesting idea, thank you for sharing!
>
> Then, yes, I agree current DAMOS might not that helpful for the situation, and
> this record feature could be useful for your case.
>
> That said, do you really need full recording of the monitoring results? If
> not, DAMOS provides DAMOS tried regions feature[1], which allows users get the
> monitoring results snapshot that include both frequency and recency of all
> regions in an efficient way. If single snapshot is not having enough
> information for you, you could collect multiple snapshots.
>
> You mentioned absence of Python on Android as a blocker of DAMOS use on the
> previous reply[2], but DAMOS tried regions feature is not depend on tracepoints
> or Python.
>
> Of course, I think you might already surveyed it but found some problems.
> Could you please share that in detail if so?
>
DAMOS tried regions feature you mentioned is not fully applicable. It needs to
apply schemes on regions. There is no available scheme we can use for our use
case. What we need is to return regions with access frequency and recency to
userspace for later use.
> [1] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n-tried-regions
> [2] https://lore.kernel.org/damon/20231129131315.GB12957@cuiyangpei/
>
>
> Thanks,
> SJ
>
> >
> > Thanks.
next prev parent reply other threads:[~2023-12-01 12:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-28 7:34 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
2023-11-30 19:44 ` SeongJae Park
2023-12-01 12:25 ` cuiyangpei [this message]
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=20231201122507.GA15806@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