Re: [PATCH v2 3/3] mm/damon/paddr: support hugetlb folios in access monitoring

[SJ Park <sj@kernel.org>]

On Wed, 02 Sep 2026 03:15:18 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [Critical] Non-atomic PTE modification in `damon_hugetlb_mkold()` clobbers hardware-updated dirty bits.
> - [High] DAMOS action appliers suffer from severe O(N) performance overhead on hugetlb pages due to PAGE_SIZE stepping.
> --
> 
> commit c04c513b2839f46c6e864892a28fa35c945f1209
> Author: Krishna Iyer <kiyer@crusoe.ai>
> 
> mm/damon/paddr: support hugetlb folios in access monitoring
> 
> This commit introduces damon_get_monitor_folio() to allow Damon's physical
> address space monitoring to sample hugetlb-backed memory. It updates the
> access monitoring primitives damon_pa_mkold() and damon_pa_young() to use
> this new function. The Damos action appliers continue to use
> damon_get_folio() to skip hugetlb folios.
> 
> >     The DAMOS action appliers (damon_pa_pageout(),
> >     damon_pa_mark_accessed_or_deactivate(), damon_pa_migrate(),
> >     damon_pa_stat()) keep using damon_get_folio(): reclaim, LRU
> >     manipulation and migration cannot act on hugetlb folios, so their
> >     behavior is unchanged.
> 
> [Severity: High]
> This is a pre-existing issue, but does this unchanged behavior cause a severe
> performance regression when Damos action appliers encounter hugetlb pages?
> 
> When damon_pa_pageout() and damon_pa_stat() (with filters) run on regions
> with hugetlb memory, damon_get_folio() rejects the hugetlb folios. This causes
> the code to fall back to PAGE_SIZE stepping:
> 
> mm/damon/paddr.c:damon_pa_pageout() {
> ...
> 	while (addr < damon_pa_phys_addr(r->ar.end, addr_unit)) {
> 		folio = damon_get_folio(PHYS_PFN(addr));
> 		if (damon_pa_invalid_damos_folio(folio, s)) {
> 			addr += PAGE_SIZE;
> 			continue;
> 		}
> ...
> }
> 
> For large folios like 1 GiB hugetlb pages, this results in hundreds of thousands
> of redundant atomic refcount operations per page (262,144 times). Does this
> PAGE_SIZE stepping need to be updated to advance by folio_size() to prevent
> massive CPU consumption by Damon threads?

For such cases DAMOS quota feature exists.  We could revisit this later, or
whenever a real user reports this as a problem.

> 
> > diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c
> > index 5c6c3a597fd0b..ed7b7f31291a0 100644
> > --- a/mm/damon/paddr.c
> > +++ b/mm/damon/paddr.c
> > @@ -37,7 +37,7 @@ static unsigned long damon_pa_core_addr(
> >  
> >  static void damon_pa_mkold(phys_addr_t paddr)
> >  {
> > -	struct folio *folio = damon_get_folio(PHYS_PFN(paddr));
> > +	struct folio *folio = damon_get_monitor_folio(PHYS_PFN(paddr));
> >  
> >  	if (!folio)
> >  		return;
> 
> [Severity: Critical]
> This is a pre-existing issue, but can this resulting call chain clobber
> hardware-updated dirty bits?
> 
> Now that damon_pa_mkold() supports hugetlb folios, it processes them via
> damon_folio_mkold_one(), which reaches damon_hugetlb_mkold(). In this
> function, the PTE is updated non-atomically:
> 
> mm/damon/ops-common.c:damon_hugetlb_mkold() {
> ...
> 	if (pte_young(entry)) {
> 		referenced = true;
> 		entry = pte_mkold(entry);
> 		set_huge_pte_at(mm, addr, pte, entry, psize);
> 	}
> ...
> }
> 
> Any hardware modifications to the PTE (like setting the dirty bit) between
> huge_ptep_get() and set_huge_pte_at() are silently overwritten. Could this
> result in data loss or memory corruption where modified memory is discarded
> without writeback?

I'm separatively working on it.

> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260902025700.17975-1-kiyer@crusoe.ai?part=3


Thanks,
SJ