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

[Gutierrez Asier]

Hi SJ and Lian,

On 9/1/2026 5:23 PM, SJ Park wrote:
> Hi Lian,
> 
> On Tue,  1 Sep 2026 14:58:35 +0800 Lian Wang <lianux.mm@xxxxxxxxx> 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?
Agree, I will submit a new patch to fix this behaviour and account for mTHP.

Lian, thanks a lot for the review and pointing this issue.>>
>> 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.
The idea of this patch was to introduce auto tuning. I think I submitted thebenchmark results when I sent the DAMOS_COLLAPSE feature.

Anyway, it shouldn't take long for me to get more data. I think it may be useful
for people to know the actual results in real application.

SJ, what's the best place to publish all those data? I believe you have more
experience sharing this data and which platform is the most useful one.>>
>> 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@xxxxxxxxx>
> 
> 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
> 
> [...]

-- 
Asier Gutierrez
Huawei