Re: [LSF/MM/BPF TOPIC] DAMON Updates: Tiering, Pagel Level Monitoring and DAMON-X

[SeongJae Park <sj@kernel.org>]

On Sat,  7 Mar 2026 13:02:48 -0800 SeongJae Park <sj@kernel.org> wrote:

> Hello,
> 
> 
> In the last year LSF/MM/BPF, I shared [1] updates of the status and future
> plans on DAMON development.  Feedbacks were very helpful.  I'd like to share
> new updates and gather more feedback on LSF/MM/BPF 2026.

As this topic is scheduled [1] for the conference (kudos to the conference
committes!) and the day is approaching, I'm sharing a few updtes.

> 
> Major topics to discuss in the session include but not limited to below three
> topics.  Of course, some changes could be made.
> 
> Followups on work items that we discussed on last LSF/MM/BPF
> ------------------------------------------------------------
> 
> DAMOS auto-tuning based memory tiering.  I worked on a more flexible evaluation
> setup for it.  I also upstreamed another DAMON extension that makes memory
> cgroup-aware memory tiering available.  An unnamed user confirmed positive test
> results of the auto-tuning based tiering.  Meanwhile other users including
> people from SK hynix and Micron are continuing development of their own memory
> tiering approaches and showing good achievements.  Because basic evaluation of
> my approach is done, I'm not actively working on this now, but working in a
> support mode for this.  I will share more details about this and discuss if
> something need to be revisited or if there are anything that DAMON can help for
> memory tiering.

Ravi from Micron is continuing their work [2], and now it is nearly ready to be
landed.  This is only a part of the topics I want to discuss on the session,
though.

> 
> Page level monitoring.  The feature, which accounts the number of pages in each
> DAMON region of user-interested type (e.g., hugepage, LRU list-position,
> belonging cgroup) has successfully upstreamed after the LSF/MM/BPF 2025.
> Because it imposes high overhead on large systems, a lightweight version of it
> was shared as a future work.  Unfortunately not much visible progress for it
> has been made so far.  Some progress on the design is made, though.  Briefly
> speaking, the idea is sampling the types of pages in each DAMON region.
> Implementation wise, users will be able to set the types of their interests,
> and DAMON will provide the counts of the samples of the interested types, in
> addition to the access frequency counter (nr_accesses). I'd like to share the
> design and get feedback.  Hopefully RFC ideas or patch series will be shared
> before the conference to help discussions.

I was able to make some progress and just posted [2] the RFC patch series.
Conference driven development works! :)

> 
> FYI, in future, the counters of interests could be extended to do the DAMON
> region merge/split based on not only access frequency but one of the
> user-defined interests.  Then DAMON might pivot from Data Access MONitor to
> Data Associativity MONitor.  It’s just somewhat possible and sounds funny for
> now.  I find no real use case of that.

I now think this is the right way to go.  This can also make page faults and
PMU events based mointoring like access check primitives addition easier to do.
I added more details about this on the 'Future Works: Long Term' section of the
cover letter of the RFC patch series [1].

> 
> New Project
> -----------
> 
> DAMON-X.  In Crusoe, which is a neocloud company that I’m now working for, we
> want to utilize DAMON for both memory efficiency and observability.  More
> specifically, we want to show the memory idle time percentiles, and run memory
> PSI-driven proactive memory reclamation.  The straightforward way would be
> doing that via DAMON sysfs interface, or DAMON user-space tool.  It requires
> some user-space programming, though.  I want the kernel to just work.  A way
> for that would be running DAMON modules that were developed for the purposes,
> namely DAMON_STAT and DASMON_RECLAIM.  But DAMON modules run in an exclusive
> manner, so we cannot run those in parallel.  The exclusiveness is required to
> avoid interference between DAMON worker threads (kdamond) for different
> modules.
> 
> I plan to let DAMON modules share kdamonds to let them run in parallel without
> interference.  The shared kdamond would be able to run on the system from the
> beginning or on demand, and directly attach/detach DAMON applications like
> DAMON_STAT, DAMON_RECLAIM, and future ones for NUMA-aware page migrations etc.
> It will work with a very minimum number of knobs in nearly automated way, but I
> plan to also extend the DAMON sysfs interface for more flexible and manual
> control of it for experiments and investigations.  With my humble naming sense,
> I’m currently calling it "DAMON Enabled Computer System", or DAMON-X in short.
> Actually this is a followup of what I shared in LPC 2024 kernel mm
> micro-conference, as a long-term DAMON project for the kernel that just works.
> I want to share Crusoe's desired use case, problems, and design of the
> currently planned solution during the session and get feedback.  Hopefully RFC
> ideas or patch series will be shared before the conference to help discussions.

I was unable to make much progress on this.  As we still have one week, I will
try to share a detailed RFC idea at least, before the conference.

> 
> More Topics Out of This Session
> -------------------------------
> 
> There are two more DAMON-related development works that are ongoing, that I
> want to discuss in LSF/MM/BPF.  Because I think those cannot be discussed in
> single session with the above three topics due to the limit of the time, I
> proposed separate sessions for them.

The two topics are also scheduled [1] for the conference.  We will have one
hour session for all three topics.  Appreciate the conference committees for
their works!

> The two topics are "production level
> access-aware THP [3]"

Asier from Huawei made DAMOS_COLLAPSE [4].  I will repost it after 7.1-rc1, and
hopefully it will be merged into mm-new by the conference.  This is only a part
of the topics I want to discuss on the session, though.

> and "per-CPUs/threads/reads/writes data access monitoring
> [4]".

The page level monitoring RFC patch series [3] is now also considered to be the
foundation for the interface of this work.

Akinobu continued thier PMU based mointoring work [5] and I now think that
could be a viable option for some of users including Crusoe, if page fault
based monitoring is rejected or delayed too long.

> 
> 
> 
> [1] https://lore.kernel.org/all/20250102222317.48760-1-sj@kernel.org/
> [2] https://lpc.events/event/18/contributions/1768/
> [3] https://lore.kernel.org/20260211050729.69719-1-sj@kernel.org
> [4] https://lore.kernel.org/20260218054320.4570-1-sj@kernel.org

[1] https://docs.google.com/spreadsheets/d/1mGEdDrWskp7Ua91jGXzquQGinorcD58DAVXhOiRp2Gg/edit?gid=1852749899#gid=1852749899
[2] https://lore.kernel.org/20260426003245.2687-1-ravis.opensrc@gmail.com
[3] https://lore.kernel.org/20260426205222.93895-1-sj@kernel.org
[4] https://lore.kernel.org/20260409150128.1566835-1-gutierrez.asier@huawei-partners.com
[5] https://lore.kernel.org/20260423004211.7037-1-akinobu.mita@gmail.com


Thanks,
SJ

[...]