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

SeongJae Park
2026-04-26T21:36:01Z

On Sun, 26 Apr 2026 14:20:45 -0700 SeongJae Park <sj@kernel.org> wrote:

> 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.

Sorry, the link marker is wrong. [3] is the link.

> 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].

Again, the above is using a wrong link marker. [3] is the right one.

Thanks,
SJ

>
> >
> > 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
>
> …