Re: [RFC PATCH v1 2/4] mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

On 4/30/2026 5:31 PM, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Critical] Divide-by-zero panic in damos_get_used_hugepage_mem_bp() when no anonymous memory is mapped.
> - [Medium] Missing sysfs string mapping for DAMOS_QUOTA_HUGEPAGE renders the metric unconfigurable via userspace.
> --
> 
> commit 46bdbb5e7c05e4c06aea38af1c50ac5407f8b9c3
> Author: Asier Gutierrez <[email protected]>
> 
> mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning
> 
> Introduce DAMOS_QUOTA_HUGEPAGE auto tuning Add a new DAMOS quota goal
> metric to measure the amount of huge page consumption to total anonymous
> memory consumption ratio.
> 
>> diff --git a/include/linux/damon.h b/include/linux/damon.h
>> index 143d024fec845..ee937b3892c68 100644
>> --- a/include/linux/damon.h
>> +++ b/include/linux/damon.h
>> @@ -174,6 +174,7 @@ enum damos_quota_goal_metric {
>>  	DAMOS_QUOTA_NODE_MEMCG_FREE_BP,
>>  	DAMOS_QUOTA_ACTIVE_MEM_BP,
>>  	DAMOS_QUOTA_INACTIVE_MEM_BP,
>> +	DAMOS_QUOTA_HUGEPAGE,
> 
> Is there a missing update to the string mapping array in sysfs for this new
> metric?
Good catch. I will fix it in the next version.
> 
> If damos_sysfs_qgoal_metric_names in mm/damon/sysfs-schemes.c isn't updated
> to include DAMOS_QUOTA_HUGEPAGE, wouldn't configuring this metric from
> userspace fail and return -EINVAL?
> 
>>  	NR_DAMOS_QUOTA_GOAL_METRICS,
>>  };
> 
> [ ... ]
> 
>> diff --git a/mm/damon/core.c b/mm/damon/core.c
>> index 1af84e0ac1dd4..63cbf30288d53 100644
>> --- a/mm/damon/core.c
>> +++ b/mm/damon/core.c
> 
> [ ... ]
> 
>> @@ -2320,6 +2320,18 @@ static unsigned int damos_get_in_active_mem_bp(bool active_ratio)
>>  	return mult_frac(inactive, 10000, total);
>>  }
>>  
>> +/*
>> + * Returns anon hugepage memory to total anon memory use ratio.
>> + */
>> +static unsigned int damos_get_used_hugepage_mem_bp(void)
>> +{
>> +	unsigned long used_hugepages, total_used;
>> +
>> +	used_hugepages = global_node_page_state(NR_ANON_THPS);
>> +	total_used = global_node_page_state(NR_ANON_MAPPED);
>> +	return mult_frac(used_hugepages, 10000, total_used);
> 
> Can total_used be zero here?
> 
> If there is no anonymous memory mapped in the system (for example, right
> after boot or on a system running purely file-backed workloads), total_used
> would evaluate to 0.
> 
> Since mult_frac() directly performs division and modulo without
> zero-checking the denominator, wouldn't passing 0 as total_used trigger a
> divide-by-zero exception and crash the kernel?
>
No, the number of anonymous memory mapped in the system is always
greater than 0.
 

-- 
Asier Gutierrez
Huawei