Re: [RFC PATCH v2 0/9] mm/damon: hardware-sampled access reports

[SJ Park <sj@kernel.org>]

Hi Lian,

On Tue, 15 Sep 2026 10:54:51 +0800 Lian Wang <lianux.mm@gmail.com> wrote:

> From: "Lian Wang (ProcessMission)" <lianux.mm@gmail.com>
> 
> Hi Ravi and SJ,
> 
> Thank you for sharing this work.  The report path looks potentially useful
> for a DAMON observation-granularity problem that we are investigating.
> 
> The scenario originated from an issue reported by SXF, and we are planning to
> share and discuss it at LPC.  We have now reproduced the underlying observation
> difference on both a local PC and an x86 server.  The server run below is our
> larger, controlled reproduction.
> 
> Our test monitors a QEMU process whose guest memory is backed by a shared
> tmpfs file.  The guest repeatedly writes one 4 KiB page in every 2 MiB range
> of a resident 48 GiB data set.  The unique 4 KiB spatial coverage of one sweep
> is about 96 MiB, or 0.195% of that data set.
> 
> Using vaddr DAMON with a 500 ms sampling interval, 20 second aggregation
> interval, and 500--2000 regions, two opposite-order runs reported a mean hot
> ratio of 1.751% without shmem PMD mappings and 75.836% with them.  A control
> that writes the full 2 MiB ranges reported 75.366% with PMD mappings.  Hence,
> in this workload the current observation does not distinguish spatially sparse
> 4 KiB activity from dense activity once the large mappings are present.

The observation makes sense.  However, does the sparse access pattern
realistic?  If so, what is the purpose or expected benefit of using huge page
for workloads having such access pattern?

> 
> We are testing existing DAMON strategy mitigations first.  As a next step, we
> plan to replay recorded access addresses through the report/probe decision
> path, independently of a live PMU, and check whether DAMOS can distinguish the
> sparse and dense cases.  In that experiment, raw report frequency and unique
> 4 KiB spatial coverage will remain separate quantities; lack of reports will
> remain unknown when source coverage or loss is insufficient.
> 
> If the report evidence makes the decision reliable, the response we want to
> evaluate is an internal, bounded PMD mapping demotion (splitting the mapping
> while retaining the underlying THP folio), rather than exposing physical folio
> split as a DAMOS action.  We will first keep the response stat-only and archive
> the would-act ranges.  After the replay result is repeatable, we can replace
> the replay producer with an appropriate hardware source and share the results.

I'm not very sure if this is the right direction.  PMD mapping demotion sounds
like you just don't want to use huge pages.  If so, you could disable huge
pages.  Answers to my above questions would be helpful for me.

> 
> This seems like a useful consumer experiment for the report interface, even if
> the vaddr and optimized transport parts belong to the later phase.  Please let
> us know if this direction conflicts with the intended report semantics.

I believe this doesn't conflict with the project, though.  Nevertheless,
technically speaking, it is not the report semantics.  Reporting allows any
information to be reported.  Page faults like information could be coarse
grained, same to the current page table accessed-bit based one.  Only finer
grained access primitive reports, like those from perf events, would increase
the accuracy for the sparse access pattern monitoring.

Whether sparse access pattern is realistic and using huge pages on systems
having such access pattern makes sense are different questions, though.

> 
> We will share the strategy, replay, and mapping-decision results once they are
> repeatable.  We are also reviewing and testing this series, and will follow up
> with the appropriate tag(s) for the exact revision if that work justifies them.

Looking forward to!  Nonetheless, it would better to make sure we are on the
same page for the above questions before digging deeper, in my humble opinion.


Thanks,
SJ

[...]