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

[SJ Park]

On Wed, 29 Jul 2026 15:05:10 +0530 Bharata B Rao <bharata@xxxxxxx> wrote:

> On 28-Jul-26 11:44 PM, Andrew Morton wrote:
> > On Tue, 28 Jul 2026 11:13:48 +0530 Bharata B Rao <bharata@xxxxxxx> 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.

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@xxxxxxxxxx/


Thanks,
SJ

[...]