DAMON reporting more hot memory on huge pages (was: "Re: [RFC PATCH v2 0/9] mm/damon: hardware-sampled access reports")

[SJ Park <sj@kernel.org>]

On Wed, 16 Sep 2026 11:44:30 +0800 "Lian Wang (ProcessMission)" <lianux.mm@gmail.com> wrote:

> Hi SJ,
> 
> Thank you for the questions.  I mixed the original field scenario and our
> controlled reproducer in my previous mail.  I also jumped from the observation
> problem to PMD mapping demotion before explaining why the deployment needs both
> huge pages and finer-grained observation.  That made it sound as if our goal
> was simply to stop using huge pages.
> 
> > 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?
> 
> The original case is not a lab-created request to use huge pages for a sparse
> microbenchmark.  It was reported by SXF from a KVM/QEMU deployment where the
> VM has a large memory allocation backed by a shared tmpfs file, host THP is
> enabled, and Oracle runs inside the guest.  They use host-side DAMON to measure
> the VM's hot-memory proportion.  With the same business memory use, they
> observed a much larger hot proportion when THP was enabled.

Thank you for clarifying this.  So I understand it is an issue from a real
world workload.  I'm still curious how sparse the real access pattern in the
real world workload is, and if there is a low haning fruit.  There might be
rooms to improve in their DAMON usage.

Could you share more details about the real world setup and findings?  More
specifically, how they define the hot proportion and how they collect the
number?  What is DAMON setup?  What are the real numbers they saw?

Also, I understand they want to understand real working set size of guests.
Could you further share what they are planning to do with the monitored working
set size?  The required level of accuracy of the monitoring could depend on the
purpose.

> 
> The guest tmpfs 4 KiB/2 MiB writer is their controlled diagnostic case for
> isolating that observation; it is not a claim that the Oracle workload is
> exactly a one-page-per-2-MiB loop.  We then reproduced and quantified the same
> effect on a PC and on the x86 server.
> 
> For this deployment, keeping large pages is a real requirement at the host
> virtualization layer.  QEMU owns a large resident guest-RAM mapping.  Host THP
> allows that mapping to use PMDs and allows KVM to use large secondary mappings,
> reducing host page-table memory, TLB and nested-page-walk pressure, and KVM
> mapping/fault overhead.  These benefits are independent of whether every 4 KiB
> page inside a particular 2 MiB range is hot at one observation time.

Thank you for clarifying this.  Now I understand why they use THP, and I fully
agree they should keep using THP.

[...]
> The performance requirement and monitoring use case come from the deployment,
> not from our lab model.  We will also report the measured Oracle/VM benefit and
> the production access distribution when those data are ready.  The diagnostic
> result establishes the observation mechanism, but it should not substitute for
> those workload-level measurements.

Thanks to your detailed and nice explanation, I don't doubt about the needs to
use huge pages.  So I wouldn't insist on Oracle/VM benefit from huge pages.

I'm still curious the real access distribution, though.  I understand you don't
have the data yet.  It would be very helpful if you could share that in future.

> 
> > 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.
> 
> I agree.  My reasoning in the previous mail was too jumpy: I went from a coarse
> observation directly to a possible MM response, and that obscured the actual
> goal.  PMD mapping demotion is not part of our current proposed solution.  The
> current direction is to keep both the huge folio and PMD mapping unchanged and
> use a genuinely fine-grained access primitive to improve the observation and
> the stat-only decision.  We should first find out whether that is sufficient
> before discussing any mapping change at all.

Thank you for clarifying.  Yes, if you really need sub-pmd access, I believe
the perf event based DAMON could be more useful.  Nonetheless, as I requested
above, knowing the DAMON usage and purpose in more detail might let us finding
a low hanging fruit.

[...]
> With this context clarified, we will return to the immediate work: use the
> existing IBS/perf-event proposal as the concrete strategy under test, and see
> whether its fine-grained evidence can improve the observation and DAMOS
> decision for this case.  We will use the results to test and review this series,
> report both improvements and remaining gaps, and not assume in advance that it
> is the final solution.

That makes sense.  Because Ravi thankfully already implemented this nice
working version prototype, there is no reason to not test it right now.

> 
> I hope this clarifies why keeping huge pages and requesting finer-grained
> observation are not contradictory requirements in this case.

Yes, it is now clear to me.  Thank you for patiently englightening me, Lian.

> 
> If I am still misunderstanding any part of your questions, or if any part of
> this explanation remains unclear, please continue to correct me.  We will keep
> sharing our findings and would like to make sure we are aligned before going
> further.

I believe testing the perf event based monitoring with Ravi's implementation is
a good path forward.

I'm curious about the real setup and results your clients got from their real
world wokload.  But that's not necessarily a blocker of the perf event based
monitoring test.


Thanks,
SJ

[...]