DAMON development mailing list
 help / color / mirror / Atom feed
From: SJ Park <sj@kernel.org>
To: SJ Park <sj@kernel.org>
Cc: damon@lists.linux.dev,
	Ravi Jonnalagadda <ravis.opensrc@gmail.com>,
	Akinobu Mita <akinobu.mita@gmail.com>,
	Andrew Paniakin <apanyaki@amazon.com>
Subject: milestone 2 proress update (was "Re: Roadmap for extending DAMON beyond pte-accessed bit")
Date: Sun, 15 Nov 2026 12:53:04 -0800	[thread overview]
Message-ID: <20261115205305.99823-1-sj@kernel.org> (raw)
In-Reply-To: <20260905171537.84217-1-sj@kernel.org>

On Sat,  5 Sep 2026 10:15:36 -0700 SJ Park <sj@kernel.org> wrote:

> On Mon, 25 May 2026 15:52:08 -0700 SeongJae Park <sj@kernel.org> wrote:
> 
> > Hello,
> > 
> > 
> > TLDR: Let's extend DAMON for data attributes monitoring, andd then further
> > extend that for multiple access check primitives including page faults, perf
> > memory-access events and optimized AMD IBS-like h/w feature drivers.
> [...]
> > Milestone 1: PTE Accessed bit as one of the data attributes
> > -----------------------------------------------------------
> > 
> > I will work on stabilizing and further extending the data attributes interface
> > and internal framework to be able to support PTE Accessed bit.  This may take
> > no small amount of efforts, but hopefully doable by the end of this year.
> > 
> > Milestone 2: First damon_report_access()-based data attribute monitoring
> > ------------------------------------------------------------------------
> > 
> > Once the first milestone is completed, we will add the damon_report_access()
> > and related infrastructure changes into the DAMON core.  On top of it, we will
> > further implement the first data attribute that utilizing the reporting
> > infrastructure.  I personally think the perf event based one is a good target
> > at the momentt.  I think so mainly because the perf maintainers didn't show
> > special concern yet.  We can discuss the target again after the first milestone
> > is completed, though.  Hopefully this is doable by the LSFMMBPF 2027.
> > 
> > The timeline is just a gut feeling.  It could be done much earlier or later.
> 
> The patch series [1] for milestone 1 is now merged into mm.git.  Having it
> merged into mm.git doesn't guarantee landing on the mainline.  More works for
> making it complete including support of vaddr and DAMOS should also be
> continued.  Refer to my another reply [2] for mroe details on the additional
> works.  But we show no concern for landing the series on the mainline as of
> now.  And the additional works are not blockers of milestone 2.
> 
> Therefore, I believe we can consider milestone 1 nearly done.  Hopefully the
> series will be merged into the mainline by 7.4, which is expected to be
> released on 2026-12-20.  Then we can officially mark milestone 1 as delivered
> on time.
> 
> So I believe it is the time to start milestone 2.  This would take time.  I
> need to start from learning perf event system.  This project is definitely
> important but I'm not dedicated to only this project.  Please bear in mind with
> me.  But I'm still optimistic to the planned timeline.  It still looks doable
> by LSFMMBPF'27.  We are still on the track.

I shared more detailed plans for milestone 2 with as a plan-only RFC v0 patch
series [1].  The plan is to implement the report infra and cpu cycle sampling
based monitoring using the infra.  Once those are done, we can move to
milestone 3 and let people implement more report based modes utilizing more
hardware features like AMD IBS, Intel PEBS and ARM SPE.

I just posted a new version of the series [2] as a formal RFC.  The high level
plan is not changed.  We will implement the cpu cycle sampling based
monitoring.  But the scope of the series is reduced.

I realized implementing CPU sampling is not a small amount of work.  It
requires no simple report infra, and understanding of perf.  It is making
progress unnecessarily slow and make the change unnecessarily big.  So I found
another simple but practical report producer: user-providing reports.

Hence the RFC v1 patch series [2] implements a very simple report system, and
user-provided report based monitoring mode, using the report system.  It is
still not very small.  The series is consisted with 27 patches.  But I believe
this is reviewable and consumable.

I will make this be merged first, and then further advance the reporting infra
and implement the cpu cycle sampling based mode.  Refer to 'Ongoing and Future
Works' section of the cover letter for more details.

Hopefully the user report series will be merged by 7.5-rc1 or 7.6-rc1.

[1] https://lore.kernel.org/20261017195747.89961-1-sj@kernel.org
[2] https://lore.kernel.org/20261115202849.99134-1-sj@kernel.org

> 
> [1] https://lore.kernel.org/20260901132506.99243-1-sj@kernel.org 
> [2] https://lore.kernel.org/20260905165221.83994-1-sj@kernel.org


Thanks,
SJ

[...]

      parent reply	other threads:[~2026-11-15 20:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-25 22:52 Roadmap for extending DAMON beyond pte-accessed bit SeongJae Park
2026-05-26  0:12 ` Ravi Jonnalagadda
2026-05-26 14:29 ` Akinobu Mita
2026-05-26 21:46   ` Ravi Jonnalagadda
2026-05-27  0:11     ` SeongJae Park
2026-06-24 14:56 ` SeongJae Park
2026-07-11  0:48   ` SJ Park
2026-09-05 16:52     ` SJ Park
2026-09-05 17:15 ` SJ Park
2026-09-06  7:43   ` Lian Wang
2026-09-06 16:36     ` SJ Park
2026-11-15 20:53   ` SJ Park [this message]

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=20261115205305.99823-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akinobu.mita@gmail.com \
    --cc=apanyaki@amazon.com \
    --cc=damon@lists.linux.dev \
    --cc=ravis.opensrc@gmail.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