Re: [PATCH v4 1/3] mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

[SJ Park <sj@kernel.org>]

Hi Lian,

On Tue,  1 Sep 2026 14:58:35 +0800 Lian Wang <lianux.mm@gmail.com> wrote:

> Hi SJ and Asier,
> 
> Thanks for working on this and for providing the server results.  I have two
> questions about what hugepage_mem_bp is intended to represent.
> 
> > Introduce DAMOS_QUOTA_HUGEPAGE_MEM_BP auto tuning. Add a new DAMOS quota
> > goal metric to measure the amount of huge page consumption to total
> > memory consumption ratio.
> 
> First, NR_ANON_THPS tracks anonymous PMD mappings, while NR_SHMEM_THPS and
> NR_FILE_THPS track PMD-mappable page-cache folios.  Therefore, splitting only
> an anonymous PMD mapping can change hugepage_mem_bp without physically
> splitting the folio.  Is the intended metric PMD-mapped memory or physical
> large-folio memory?  Clarifying this and adding a mapping-only test may help.

Good point.  I was just missing this.  So, hugepage_mem_bp is not accounting
anon mTHPs, right?  Since hugepage_mem_bp is for general hugepages, I think
this is better to be improved.  Seems using MTHP_STAT_NR_ANON that is exposed
as 'nr_anon' can be used?  Because this is an improvement rather than a fix of
a bug, I think doing this as either a followup or new version of this series
are ok.  Asier, what do you think?

> 
> Second, the metric is global while a DAMOS scheme can target one process.

Actually it can target multiple processes if those are in single DAMON context.

> THPs from other processes or NUMA nodes can satisfy the target or dilute the
> monitored process's changes.  Is this intentional?

I think it is intentional.  The user should have the control on collapsing
hugepages, or believe the uncontrolled collapse mechanisms.

> If so, documenting the
> scope and testing a background THP workload may be useful.

More documentation and testing are always welcome :)

> 
> The temporal results approach the 10% and 25% targets, while the consistent
> results overshoot the 10% target to about 20% and 45%.  I would describe this
> as control-response data.  TPS, latency, TLB, fragmentation and collapse CPU
> data could further show the workload benefit and cost.

Yes, those would be helpful.  That's not mandatory for this simple change in my
opinion, though.  I would let Asier decide whether and when to make and share
such data.

> 
> If I have misunderstood any of this, please feel free to ignore these
> comments and correct me.

Your comments are very helpful, thank you for your review and comments, Lian.

> 
> The enum, quota-goal wiring and sysfs exposure otherwise look consistent with
> the existing DAMOS autotuning framework.  I consider the points above
> follow-up questions about semantics and evaluation, rather than blockers for
> this series.

I agree.

> 
> For the series:
> 
> Reviewed-by: Lian Wang <lianux.mm@gmail.com>

Thank you!

> 
> Please feel free to Cc me on related follow-up patches.  I am happy to help
> review the code.  Besides my own DAMON work, I have recently been reviewing
> and learning from other DAMON and MM work, and I would be glad to continue.

I'm curious if you and general reviewers need or prefer to directly be Cc-ed.
I was naively thinking people can search and review DAMON patches by
subscribing to the mailing list or using the archives via lore.kernel.org like
tools.


Thanks,
SJ

[...]