From: SeongJae Park <sj@kernel.org>
To: cuiyangpei <cuiyangpei@gmail.com>
Cc: SeongJae Park <sj@kernel.org>,
akpm@linux-foundation.org, damon@lists.linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
xiongping1@xiaomi.com
Subject: Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
Date: Mon, 22 Jan 2024 09:56:11 -0800 [thread overview]
Message-ID: <20240122175611.46371-1-sj@kernel.org> (raw)
In-Reply-To: <20240122054631.GA7880@cuiyangpei>
Hi cuiyangpei,
On Mon, 22 Jan 2024 13:46:31 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> On Sun, Dec 03, 2023 at 07:37:45PM +0000, SeongJae Park wrote:
> > On 2023-12-03T13:43:13+08:00 cuiyangpei <cuiyangpei@gmail.com> wrote:
> >
> > > On Fri, Dec 01, 2023 at 05:31:12PM +0000, SeongJae Park wrote:
> > > > Hi Cuiyangpei,
> > > >
> > > > On Fri, 1 Dec 2023 20:25:07 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > > >
> > > > > 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 set 'access_pattern' and 'stat' action in schemes when apps are on
> foreground, record apps' memory access pattern when they are switched
> to the background with 'update_schemes_tried_regions' state. But it
> catch the snapshot after next aggregation interval. DAMON is still
> sampling during the app switches to the background and the next
> aggregation time, which can cause the value of "age" to change. The
> sampling results during this period cannot accurately reflect the app's
> foreground access pattern.
>
> Is there any way to catch sampling result immediately after setting the
> "update_schemes_tried_regions" state?
There is no way for exactly doing this. You would need to proactively collect
snapshots while the app is foreground, and use the latest one that collected
before the app goes background, like recording-based approach would do.
I think recent DAMON changes might make an alternative approach available,
though. From v6.7, DAMON provides pseudo-moving-average monitoring result in
sampling interval granualrity, since patchset "mm/damon: provide pseudo-moving
sum based access rate". And a followup patchset, namely "mm/damon: implement
DAMOS apply intervals", has made DAMOS works in the sampling interval
granualrity. Both patchsets are merged into v6.7-rc1.
Hence, I think you could use 'update_schemes_tried_regions' after you noticed
the app's state transition, with DAMOS apply interval of one sampling interval.
Then you will get the monitoring results after one sampling interval. Of
course, the snapshot may contain some of background access pattern, but
wouldn't made it changed significantly, unless you set aggregation interval too
short.
> Alternatively, can it return the "last_nr_accesses" and "last_age" values in
> tried_regions/<N> directory?
This could also be a good alternative in my think. Nice idea. But, because
the previously mentioned alternative is already available while this require a
bit small but additional changes, could we check if the previously one make
sense and works first? We could revisit this idea if it turns out the previous
alternative is not suffice in my opinion.
>
> Do you have any other suggestions?
As I mentioned above, I'd suggest the DAMOS apply interval of single sampling
interval for now.
Thanks,
SJ
>
> Thanks.
next prev parent reply other threads:[~2024-01-22 17:56 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
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 [this message]
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=20240122175611.46371-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cuiyangpei@gmail.com \
--cc=damon@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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).