From: SeongJae Park <sj@kernel.org>
To: sashiko-bot@kernel.org
Cc: SeongJae Park <sj@kernel.org>, damon@lists.linux.dev
Subject: Re: [RFC PATCH 1/7] mm/damon: introduce damon_set_region_system_rams_default()
Date: Tue, 14 Apr 2026 20:36:44 -0700 [thread overview]
Message-ID: <20260415033647.77164-1-sj@kernel.org> (raw)
In-Reply-To: <20260415013553.43E4EC19425@smtp.kernel.org>
TL; DR: Sashiko found no real issue of this patch.
On Wed, 15 Apr 2026 01:35:52 +0000 sashiko-bot@kernel.org wrote:
> Sashiko AI review found 1 potential issue(s):
> - [High] Creation of a single bounding box region for all System RAM severely degrades monitoring accuracy on sparse memory topologies by including non-RAM holes.
> --
>
> commit 8f8f43643f81a1ce41ad12d7eb7416faa6e23114
> Author: SeongJae Park <sj@kernel.org>
>
> mm/damon: introduce damon_set_region_system_rams_default()
>
> This commit introduces a function to set the default target region to
> cover all System RAM resources instead of just the largest one. It finds
> the start of the first resource and the end of the last resource, and
> sets this bounding box as the target region.
>
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index 12544c60531d3..91e14caa4f6a1 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> [ ... ]
> > +static int damon_system_ram_walk_fn(struct resource *res, void *arg)
> > +{
> > + struct damon_system_ram_range_walk_arg *a = arg;
> > +
> > + if (!a->walked) {
> > + a->walked = true;
> > + a->res.start = res->start;
> > + }
> > + a->res.end = res->end;
> > + return 0;
> > +}
> [ ... ]
> > +int damon_set_region_system_rams_default(struct damon_target *t,
> > + unsigned long *start, unsigned long *end,
> > + unsigned long addr_unit, unsigned long min_region_sz)
> > +{
> > + struct damon_addr_range addr_range;
> > +
> > + if (*start > *end)
> > + return -EINVAL;
> > +
> > + if (!*start && !*end &&
> > + !damon_find_system_rams_range(start, end, addr_unit))
> > + return -EINVAL;
> > +
> > + addr_range.start = *start;
> > + addr_range.end = *end;
> > + return damon_set_regions(t, &addr_range, 1, min_region_sz);
>
> Could this create a single bounding box region that includes large non-RAM
> holes on systems with sparse memory layouts?
>
> Since damon_system_ram_walk_fn() only records the minimum start address and
> maximum end address across all System RAM resources, creating a single
> contiguous damon_addr_range from this bounding box includes any
> intervening address gaps.
>
> On multi-socket NUMA systems or devices with large MMIO holes, this
> could result in massive address ranges not backed by actual RAM. Because
> DAMON uniformly samples random addresses within each region, sampling
> might predominantly hit these unbacked memory holes.
>
> Would this dilute the access sampling and cause actively used memory to be
> incorrectly classified as cold? Should the code gather discrete System RAM
> ranges into an array of struct damon_addr_range and pass them to
> damon_set_regions() with nr_ranges > 1 to exclude holes?
This is true. But it shouldn't cause real problems because of the adaptive
regions adjustment mechniasm of DAMON, as also mentioned on the cover letter.
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260415012048.76508-1-sj@kernel.org?part=1
Thanks,
SJ
next prev parent reply other threads:[~2026-04-15 3:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 1:20 [RFC PATCH 0/7] mm/damon/reclaim,lru_sort: monitor all system rams by default SeongJae Park
2026-04-15 1:20 ` [RFC PATCH 1/7] mm/damon: introduce damon_set_region_system_rams_default() SeongJae Park
2026-04-15 1:35 ` sashiko-bot
2026-04-15 3:36 ` SeongJae Park [this message]
2026-04-15 1:20 ` [RFC PATCH 2/7] mm/damon/reclaim: cover all system rams SeongJae Park
2026-04-15 1:58 ` sashiko-bot
2026-04-15 3:47 ` SeongJae Park
2026-04-15 1:20 ` [RFC PATCH 3/7] mm/damon/lru_sort: " SeongJae Park
2026-04-15 2:36 ` sashiko-bot
2026-04-15 3:52 ` SeongJae Park
2026-04-15 1:20 ` [RFC PATCH 4/7] mm/damon/core: remove damon_set_region_biggest_system_ram_default() SeongJae Park
2026-04-15 1:20 ` [RFC PATCH 5/7] mm/damon/stat: use damon_set_region_system_rams_default() SeongJae Park
2026-04-15 1:20 ` [RFC PATCH 6/7] Docs/admin-guide/mm/damon/reclaim: update for entire memory monitoring SeongJae Park
2026-04-15 1:20 ` [RFC PATCH 7/7] Docs/admin-guide/mm/damon/lru_sort: " SeongJae Park
2026-04-15 2:57 ` sashiko-bot
2026-04-15 3:53 ` 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=20260415033647.77164-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=damon@lists.linux.dev \
--cc=sashiko-bot@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.