All of lore.kernel.org
 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 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.