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
next prev parent 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