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

[Bharata B Rao <bharata@amd.com>]

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

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

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.

So I would see DAMON and pghot as complementary rather than one replacing
the other. 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.

> 
> Thanks, I'll await review input on this.
> 
> AI review had much to say:
> 	https://sashiko.dev/#/patchset/20260728054356.291998-1-bharata@amd.com

Thanks, will address those comments.

Regards,
Bharata.