DAMON development mailing list
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "SeongJae Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [PATCH 3/7] mm/damon/lru_sort: cover all system rams
Date: Wed, 29 Apr 2026 06:03:13 +0000	[thread overview]
Message-ID: <20260429060314.49EE6C19425@smtp.kernel.org> (raw)
In-Reply-To: <20260429041232.90257-4-sj@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Single bounding box for sparse memory layouts causes soft lockups and algorithmic failure
--

commit 692650636f4214ec9c2fa1c5d7fd43fe3bf049fe
Author: SeongJae Park <sj@kernel.org>

mm/damon/lru_sort: cover all system rams

This commit changes the default monitoring region from the biggest System RAM
resource to a single region that spans all system RAMs. This is intended to
cover the entire physical memory instead of just the largest block.

> diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c
> index 7569e471160a..2eb559d913b6 100644
> --- a/mm/damon/lru_sort.c
> +++ b/mm/damon/lru_sort.c

[ ... ]

> @@ -326,7 +328,7 @@ static int damon_lru_sort_apply_parameters(void)
>  	if (err)
>  		goto out;
>  
> -	err = damon_set_region_biggest_system_ram_default(param_target,
> +	err = damon_set_region_system_rams_default(param_target,
>  					&monitor_region_start,
>  					&monitor_region_end,
>  					param_ctx->addr_unit,

Could this lead to a regression on systems with sparse memory layouts?

When creating a single bounding box from the first to the last physical
address, systems with sparse memory like CXL or distant NUMA nodes could end
up with a region containing terabytes of unpopulated physical address space.

Will this cause soft lockups during DAMOS operations?

If a scheme like PAGEOUT iterates linearly over this massive region in
PAGE_SIZE increments, iterating over these large memory holes might stall the
CPU and trigger the watchdog, since cond_resched() is typically placed after
the loop.

Does this also cause an algorithmic regression with the sampling probability?

DAMON's adaptive logic merges adjacent regions with identical access
frequencies. Since memory holes report 0 accesses, they might be aggressively
merged with interspersed RAM into maximum-sized regions. Because sampling
selects a single random address per region, the probability of actually
sampling the populated RAM might drop to near zero.

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

  reply	other threads:[~2026-04-29  6:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-29  4:12 [PATCH 0/7] mm/damon/reclaim,lru_sort: monitor all system rams by default SeongJae Park
2026-04-29  4:12 ` [PATCH 1/7] mm/damon: introduce damon_set_region_system_rams_default() SeongJae Park
2026-04-29  4:39   ` sashiko-bot
2026-04-29  5:22     ` SeongJae Park
2026-04-29  4:12 ` [PATCH 2/7] mm/damon/reclaim: cover all system rams SeongJae Park
2026-04-29  5:23   ` sashiko-bot
2026-04-29  5:41     ` SeongJae Park
2026-04-29  4:12 ` [PATCH 3/7] mm/damon/lru_sort: " SeongJae Park
2026-04-29  6:03   ` sashiko-bot [this message]
2026-04-29  6:06     ` SeongJae Park
2026-04-29  4:12 ` [PATCH 4/7] mm/damon/core: remove damon_set_region_biggest_system_ram_default() SeongJae Park
2026-04-29  4:12 ` [PATCH 5/7] mm/damon/stat: use damon_set_region_system_rams_default() SeongJae Park
2026-04-29  4:12 ` [PATCH 6/7] Docs/admin-guide/mm/damon/reclaim: update for entire memory monitoring SeongJae Park
2026-04-29  7:02   ` sashiko-bot
2026-04-29 14:27     ` SeongJae Park
2026-04-29  4:12 ` [PATCH 7/7] Docs/admin-guide/mm/damon/lru_sort: " SeongJae Park
2026-04-29 14:30 ` [PATCH 0/7] mm/damon/reclaim,lru_sort: monitor all system rams by default SeongJae 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=20260429060314.49EE6C19425@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=sashiko@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox