All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "SJ Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [RFC PATCH v1.2 7/8] mm/damon/core: handle extreme memory state in get_node_memcg_used_bp()
Date: Mon, 31 Aug 2026 18:41:52 +0000	[thread overview]
Message-ID: <20260831184153.330251F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260831140254.72004-8-sj@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incorrect fallback values in `damos_get_node_mem_bp` when `i.freeram` exceeds `i.totalram`.
--

commit a048cc23be81d8e450e9ee2ce22eb0a86b0cb1ba
Author: SJ Park <sj@kernel.org>

mm/damon/core: handle extreme memory state in get_node_memcg_used_bp()

This commit handles extreme corner cases where total memory is zero or
reported used memory exceeds total memory. It updates
damos_get_node_memcg_used_bp() to prevent division by zero or underflows by
clamping the results to 100% or 0% appropriately.

Link: https://lore.kernel.org/20260329154813.47382-1-sj@kernel.org

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 75d71ac09515e..3779a04753061 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -2863,6 +2863,12 @@ static unsigned long damos_get_node_memcg_used_bp(
>  	mem_cgroup_put(memcg);
>  
>  	si_meminfo_node(&i, goal->nid);
> +	if (!i.totalram || i.totalram < used_pages) {
> +		if (goal->metric == DAMOS_QUOTA_NODE_MEMCG_USED_BP)
> +			return 10000;
> +		else	/* DAMOS_QUOTA_NODE_MEMCG_FREE_BP */
> +			return 0;
> +	}

[Severity: High]
This is a pre-existing issue, but I noticed a similar block of code just
above this in damos_get_node_mem_bp() that appears to handle the fallback
logic incorrectly:

mm/damon/core.c:damos_get_node_mem_bp() {
    ...
    si_meminfo_node(&i, goal->nid);
    if (!i.totalram || i.totalram < i.freeram) {
        if (goal->metric == DAMOS_QUOTA_NODE_MEM_USED_BP)
            return 10000;
        else    /* DAMOS_QUOTA_NODE_MEM_FREE_BP */
            return 0;
    }
    ...
}

When i.freeram exceeds i.totalram (which can happen due to per-CPU stat drift
during large frees or memory hot-remove), this logic returns 10000 (100%) for
DAMOS_QUOTA_NODE_MEM_USED_BP and 0 for DAMOS_QUOTA_NODE_MEM_FREE_BP.

Since the node is effectively completely free, shouldn't it return 0 for used
and 10000 for free?

Could this cause DAMON memory reclaim schemes to trigger aggressively on
nodes that are actually completely free, potentially causing performance
regressions?

>  	if (goal->metric == DAMOS_QUOTA_NODE_MEMCG_USED_BP)
>  		numerator = used_pages;
>  	else	/* DAMOS_QUOTA_NODE_MEMCG_FREE_BP */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831140254.72004-1-sj@kernel.org?part=7

  reply	other threads:[~2026-08-31 18:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31 14:02 [RFC PATCH v1.2 0/8] mm/damon: fix DAMOS bugs in core, paddr and vaddr SJ Park
2026-08-31 14:02 ` [RFC PATCH v1.2 1/8] mm/damon/core: skip applying scheme if region split for quota fails SJ Park
2026-08-31 17:45   ` sashiko-bot
2026-08-31 14:02 ` [RFC PATCH v1.2 2/8] mm/damon/paddr: respect folio end for DAMOS_STAT SJ Park
2026-08-31 17:54   ` sashiko-bot
2026-08-31 14:02 ` [RFC PATCH v1.2 3/8] mm/damon/paddr: respect folio end for DAMOS actions except STAT SJ Park
2026-08-31 18:06   ` sashiko-bot
2026-08-31 14:02 ` [RFC PATCH v1.2 4/8] mm/damon/vaddr: respect folio end for DAMOS_STAT SJ Park
2026-08-31 18:14   ` sashiko-bot
2026-08-31 14:02 ` [RFC PATCH v1.2 5/8] mm/damon/vaddr: respect folio end for DAMOS_MIGRATE_{HOT,COLD} SJ Park
2026-08-31 18:23   ` sashiko-bot
2026-08-31 14:02 ` [RFC PATCH v1.2 6/8] mm/damon/core: handle extreme memory state in damon_get_node_mem_bp() SJ Park
2026-08-31 18:29   ` sashiko-bot
2026-08-31 14:02 ` [RFC PATCH v1.2 7/8] mm/damon/core: handle extreme memory state in get_node_memcg_used_bp() SJ Park
2026-08-31 18:41   ` sashiko-bot [this message]
2026-09-01  0:36     ` SJ Park
2026-08-31 14:02 ` [RFC PATCH v1.2 8/8] mm/damon/core: handle extreme memory state in get_in_active_mem_bp() SJ Park
2026-08-31 18:49   ` sashiko-bot
2026-09-01  0:37     ` SJ Park
2026-09-01  0:50 ` [RFC PATCH v1.2 0/8] mm/damon: fix DAMOS bugs in core, paddr and vaddr 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=20260831184153.330251F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sj@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.