Re: [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure

[SJ Park <sj@kernel.org>]

On Wed, 29 Jul 2026 06:54:18 -0700 SJ Park <sj@kernel.org> wrote:

> On Wed, 29 Jul 2026 15:05:10 +0530 Bharata B Rao <bharata@amd.com> wrote:
> 
> > On 28-Jul-26 11:44 PM, Andrew Morton wrote:
> > > On Tue, 28 Jul 2026 11:13:48 +0530 Bharata B Rao <bharata@amd.com> wrote:
> > > 
> > >> This patchset introduces pghot, a subsystem for hot page tracking and
> > >> promotion.
> > > 
> > > Can DAMON be used to do this sort of thing adequately?
> > 
> > That really depends on the goal I believe, let me expand...
> 
> Thank you Bharata, this clearly explains me your view.  I find a few little
> gaps between yours and mine, though.  Let me clarify below.
> 
> > 
> > DAMON can indeed migrate hot pages today via DAMOS_MIGRATE_HOT, and
> > IIUC it can even do promotion and demotion together that auto-tunes
> > to a target node utilization. So for someone who wants to write a
> > per-workload, per-process tiering policy from user space, DAMON is a
> > good fit and I don't think pghot competes with it there.
> > 
> > But the intent behind pghot isn't really to be another migration
> > policy. It is to build a common in-kernel infrastructure that can act
> > as a single promotion subsystem, fed by multiple sources, with the
> > promotion engine and its heuristics (rate limiting, dynamic threshold)
> > living in one place rather than in the scheduler. Hint faults are just
> > the first source. The IBS Memory Profiler, which gives access
> > information directly from the hardware, is the other one. CXL HMU can be
> > another potential source. Hence the design centers on an exact, per-PFN
> > record that any of these sources can update, rather than on sampling.
> > 
> > The per-page, source-driven model is where the two differ the most.
> > DAMON estimates hotness by sampling one page per region per interval,
> > which is low overhead and self-contained, but it may miss a hot page
> > inside a region.
> 
> DAMON can do [1] fixed granularity monitoring, down to page size.  Of course it
> increases overhead.  A few people are using DAMON in this way, though, and we
> are working together to optimize it.
> 
> > pghot records every reported access at PFN granularity,
> > so it does not miss, but in turn it relies on a source to report the access.
> 
> DAMON is not designed to use only the single source.  We started working [2] on
> extending DAMON for multiple sources including AMD IBS.  A few working
> prototpyes are shared.  We plan to share the first version at next LSFMMBPF.
> 
> > 
> > The other practical difference is that pghot works with no user-space
> > agent at all. With numa_balancing=2 the promotion just happens, and in
> > fact pghot takes over the mode-2 promotion path that currently sits in
> > the scheduler. DAMON, outside of its built-in modules, expects a
> > controller in user space to drive it, IIUC.
> 
> For a level of auto-tuned hot/cold pages promotion/demotion, DAMON-based memory
> tiering doesn't require user-space agent, either.  Only a number of simple
> sysfs file writes are needed at the beginning.
> 
> > 
> > So I would see DAMON and pghot as complementary rather than one replacing
> > the other.
> 
> I have no strong opinion.
> 
> > In fact DAMON could well become one of the sources feeding
> > pghot, and conversely pghot's batched, rate-limited engine could serve
> > as a migration backend.

One thing to add for clarification.  DAMON is not only for monitoring.  It also
provides a general access pattern based operation engine, a.k.a DAMOS.  It
provides auto-tuned rate limiting (a.k.a DAMOS quota) and flexible filtering.

Hence, yet another imaginable way of the collaboration is plugging things in
the opposite way.  pghot's multi-source access monitoring becomes additional
access check primitives feeding DAMON, and DAMON serves as a migration backend
with its auto-tuned rate limiting and filtering.  I proposed
damon_report_access() in LSFMMBPF'25, suggesting this kind of collaboration as
one of possible use cases.

> 
> Makes sense to me.  If there are needs, we are open to add new DAMON APIs.
> 
> [1] https://origin.kernel.org/doc/html/latest/mm/damon/faq.html#can-i-simply-monitor-page-granularity
> [2] https://lore.kernel.org/all/20260525225208.1179-1-sj@kernel.org/
> 
> 
> Thanks,
> SJ
> 
> [...]
> 


Thanks,
SJ