From: SeongJae Park <sj@kernel.org>
To: SeongJae Park <sj@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <liam@infradead.org>,
David Hildenbrand <david@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Lorenzo Stoakes <ljs@kernel.org>, Michal Hocko <mhocko@suse.com>,
Mike Rapoport <rppt@kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@kernel.org>,
damon@lists.linux.dev, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 0/7] mm/damon/reclaim,lru_sort: monitor all system rams by default
Date: Wed, 29 Apr 2026 07:30:52 -0700 [thread overview]
Message-ID: <20260429143053.93890-1-sj@kernel.org> (raw)
In-Reply-To: <20260429041232.90257-1-sj@kernel.org>
On Tue, 28 Apr 2026 21:12:22 -0700 SeongJae Park <sj@kernel.org> wrote:
> DAMON_RECLAIM and DAMON_LRU_SORT set the biggest 'System RAM' resource
> of the system as the default monitoring target address range. The main
> intention behind the design is to minimize the overhead coming from
> monitoring of non-System RAM areas.
>
> This could result in an odd setup when there are multiple discrete
> System RAMs of considerable sizes. For example, there are System RAMs
> each having 500 GiB size. In this case, only the first 500 GiB will be
> set as the monitoring region by default. This is particularly common on
> NUMA systems. Hence the modules allow users to set the monitoring
> target address range using the module parameters if the default setup
> doesn't work for them. In other words, the current design trades ease
> of setup for lower overhead.
>
> However, because DAMON utilizes the sampling based access check and the
> adaptive regions adjustment mechanisms, the overhead from the monitoring
> of non-System RAM areas should be negligible in most setups. Meanwhile,
> the setup complexity is causing real headaches for users who need to run
> those modules on various types of systems. That is, the current
> tradeoff is not a good deal.
>
> Set the physical address range that can cover all System RAM areas of
> the system as the default monitoring regions for DAMON_RECLAIM and
> DAMON_LRU_SORT.
FYI, Sashiko reviews and my review of the reviews are available on replies to
this thread that Cc-ing only me and damon@lists.linux.dev
(https://lore.kernel.org/20260429041232.90257-1-sj@kernel.org). In short, no
real issue that blocks this series is found by Sashiko.
Thanks,
SJ
[...]
prev parent reply other threads:[~2026-04-29 14:30 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
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 ` SeongJae Park [this message]
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=20260429143053.93890-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=damon@lists.linux.dev \
--cc=david@kernel.org \
--cc=liam@infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--cc=vbabka@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.