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

[Lian Wang]

From: "Lian Wang (ProcessMission)" <lianux.mm@xxxxxxxxx>

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.

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.

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.

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.

Thanks,
Lian

On Thu, 10 Sep 2026 10:16:14 -0700 Ravi Jonnalagadda <ravis.opensrc@xxxxxxxxx> wrote:

> This series lets DAMON take its access information from a hardware sampler
> instead of from a page-table scan, and lets a scheme's score be weighted by what
> that sampler reported.

Sent using hkml (https://github.com/sjp38/hackermail)