DAMON development mailing list
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Liew Rui Yan" <aethernet65535@gmail.com>
Cc: damon@lists.linux.dev
Subject: Re: [RFC PATCH] mm/damon/reclaim: add 'available' memory as an optional watermarks metric
Date: Fri, 26 Jun 2026 08:24:06 +0000	[thread overview]
Message-ID: <20260626082407.549071F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260626081038.46569-1-aethernet65535@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Integer overflow in `DAMOS_WMARK_AVAILABLE_MEM_RATE` metric calculation on 32-bit systems with large RAM.
--

commit 6e3a23f197986b131330f066a94d4821743b7d21
Author: Liew Rui Yan <aethernet65535@gmail.com>

mm/damon/reclaim: add 'available' memory as an optional watermarks metric

This commit introduces a new 'memrate_type' sysfs parameter to DAMON_RECLAIM.
It allows users to switch the watermark metric evaluation from free memory to
available memory, which is particularly useful on devices like Android that
maintain low free memory.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 7e4b9affc5b06..f12d06081d70f 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c

[ ... ]

> @@ -3300,11 +3300,17 @@ static bool kdamond_need_stop(struct damon_ctx *ctx)
>  static int damos_get_wmark_metric_value(enum damos_wmark_metric metric,
>  					unsigned long *metric_value)
>  {
> +	long available_pages;
> +
>  	switch (metric) {
>  	case DAMOS_WMARK_FREE_MEM_RATE:
>  		*metric_value = global_zone_page_state(NR_FREE_PAGES) * 1000 /
>  		       totalram_pages();
>  		return 0;
> +	case DAMOS_WMARK_AVAILABLE_MEM_RATE:
> +		available_pages = si_mem_available();
> +		*metric_value = available_pages * 1000 / totalram_pages();

[Severity: Low]
Can this calculation overflow on 32-bit systems with a large amount of memory?

Since available_pages is a long type, on 32-bit architectures it is a 32-bit
integer. If the system's available memory exceeds roughly 17.1 GB (about
4,294,967 pages), multiplying available_pages by 1000 before the division would
overflow the maximum 32-bit value.

This truncation could result in an artificially low watermark metric rate.

Would it be safer to cast available_pages to a 64-bit type or use mult_frac() 
to prevent the potential overflow, even if such large memory sizes are uncommon
on 32-bit targets?

> +		return 0;
>  	default:
>  		break;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260626081038.46569-1-aethernet65535@gmail.com?part=1

  reply	other threads:[~2026-06-26  8:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26  8:10 [RFC PATCH] mm/damon/reclaim: add 'available' memory as an optional watermarks metric Liew Rui Yan
2026-06-26  8:24 ` sashiko-bot [this message]
2026-06-26 14:18 ` SeongJae Park
2026-06-27 21:36   ` Liew Rui Yan
2026-06-27 22:26     ` SJ Park
2026-06-28  8:55       ` Liew Rui Yan
2026-06-28 17:04         ` SJ Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260626082407.549071F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=aethernet65535@gmail.com \
    --cc=damon@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox