From: SeongJae Park <sj@kernel.org>
To: Ravi Jonnalagadda <ravis.opensrc@gmail.com>
Cc: SeongJae Park <sj@kernel.org>,
damon@lists.linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
akpm@linux-foundation.org, corbet@lwn.net, bijan311@gmail.com,
ajayjoshi@micron.com, honggyu.kim@sk.com, yunjeong.mun@sk.com
Subject: Re: [PATCH v9.2] mm/damon: add node_eligible_mem_bp goal metric
Date: Tue, 28 Apr 2026 08:31:06 -0700 [thread overview]
Message-ID: <20260428153106.125910-1-sj@kernel.org> (raw)
In-Reply-To: <20260428030520.701-1-ravis.opensrc@gmail.com>
On Mon, 27 Apr 2026 20:05:20 -0700 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:
> Background and Motivation
> =========================
>
> In heterogeneous memory systems, controlling memory distribution across
> NUMA nodes is essential for performance optimization. This patch enables
> system-wide page distribution with target-state goals such as "maintain
> 60% of scheme-eligible memory on DRAM" using PA-mode DAMON schemes.
>
> Rather than using absolute thresholds, this metric tracks the ratio of
> memory that matches each scheme's access pattern filters on a target
> node, enabling the quota system to automatically adjust migration
> aggressiveness to maintain the desired distribution.
>
> What This Metric Measures
> =========================
>
> node_eligible_mem_bp:
> scheme_eligible_bytes_on_node / total_scheme_eligible_bytes * 10000
>
> Two-Scheme Setup for Hot Page Distribution
> ==========================================
>
> For maintaining 60% of hot memory on DRAM (node 0) and 40% on CXL
> (node 1):
>
> PULL scheme: migrate_hot to node 0
> goal: node_eligible_mem_bp, nid=0, target=6000
> addr filter: node 1 address range (only migrate FROM CXL)
> "Move hot pages to DRAM if less than 60% of hot data is in DRAM"
>
> PUSH scheme: migrate_hot to node 1
> goal: node_eligible_mem_bp, nid=1, target=4000
> addr filter: node 0 address range (only migrate FROM DRAM)
> "Move hot pages to CXL if less than 40% of hot data is in CXL"
>
> Each scheme independently measures its own eligible memory and adjusts
> its quota to achieve its target ratio. The schemes work in concert
> through DAMON's unified monitoring context, with the quota autotuner
> balancing their relative aggressiveness.
>
> Implementation Details
> ======================
>
> The implementation adds a new quota goal metric type
> DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP to the existing DAMOS quota goal
> framework. When this metric is configured for a scheme:
>
> 1. During each quota adjustment cycle, damos_get_node_eligible_mem_bp()
> is called to calculate the current memory distribution.
>
> 2. The function iterates through all regions that match the scheme's
> access pattern (via __damos_valid_target()) and calculates:
> - Total eligible bytes across all nodes
> - Eligible bytes specifically on the target node (goal->nid)
>
> 3. For each eligible region, damos_calc_eligible_bytes() walks through
> the physical address range, using damon_get_folio() to look up
> each folio and determine its NUMA node via folio_nid().
>
> 4. Large folios are handled by calculating the exact overlap between
> the region boundaries and folio boundaries, ensuring accurate
> byte counts even when regions partially span folios.
>
> 5. The ratio (node_eligible / total_eligible * 10000) is returned
> as basis points, which the quota autotuner uses to adjust the
> scheme's effective quota size (esz).
>
> The implementation requires CONFIG_DAMON_PADDR since damon_get_folio()
> is only available for physical address space monitoring.
>
> Testing Results
> ===============
>
> Functionally tested on a two-node heterogeneous memory system with DRAM
> (node 0) and CXL memory (node 1). A PUSH+PULL scheme configuration using
> migrate_hot actions was used to reach a target hot memory ratio between
> the two tiers.
>
> With the TEMPORAL tuner, the system converges quickly to the target
> distribution. The tuner drives esz to maximum when under goal and to
> zero once the goal is met, forming a simple on/off feedback loop that
> stabilizes at the desired ratio.
>
> With the CONSIST tuner, the scheme still converges but more slowly, as
> it migrates and then throttles itself based on quota feedback. The time
> to reach the goal varies depending on workload intensity.
>
> Note: This metric works with both TEMPORAL and CONSIST goal tuners.
>
> Suggested-by: SeongJae Park <sj@kernel.org>
> Signed-off-by: Ravi Jonnalagadda <ravis.opensrc@gmail.com>
> Reviewed-by: SeongJae Park <sj@kernel.org>
So, this looks good to me. I find no blocker [1] from Sashiko review, too. I
added this to damon/next tree. Unless others find concerns or this is added to
mm-new by Andrew soon, I will repost this for mm-new merge.
[1] https://lore.kernel.org/20260428035754.116202-1-sj@kernel.org
Thanks,
SJ
[...]
prev parent reply other threads:[~2026-04-28 15:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-28 3:05 [PATCH v9.2] mm/damon: add node_eligible_mem_bp goal metric Ravi Jonnalagadda
2026-04-28 15:31 ` 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=20260428153106.125910-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=ajayjoshi@micron.com \
--cc=akpm@linux-foundation.org \
--cc=bijan311@gmail.com \
--cc=corbet@lwn.net \
--cc=damon@lists.linux.dev \
--cc=honggyu.kim@sk.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ravis.opensrc@gmail.com \
--cc=yunjeong.mun@sk.com \
/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