linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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: [RFC PATCH v3 0/4] mm/damon: Introduce node_eligible_mem_bp and node_ineligible_mem_bp Quota Goal Metrics
Date: Mon, 23 Feb 2026 21:36:33 -0800	[thread overview]
Message-ID: <20260224053633.58448-1-sj@kernel.org> (raw)
In-Reply-To: <20260223123232.12851-1-ravis.opensrc@gmail.com>

Hello Ravi,

On Mon, 23 Feb 2026 12:32:28 +0000 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:

> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> This series introduces two new DAMON quota goal metrics for controlling
> memory migration in heterogeneous memory systems (e.g., DRAM and CXL
> memory tiering) using physical address (PA) mode monitoring.

Thank you for keep working on and sharing this :)

> 
> v2: https://lore.kernel.org/linux-mm/20260129215814.1618-1-ravis.opensrc@gmail.com/
> 
> Changes since v2:
> =================
> 
> - Split single metric into two complementary metrics:
>   * node_eligible_mem_bp: hot memory present ON the specified node
>   * node_ineligible_mem_bp: hot memory NOT on the specified node.
>   This enables both PUSH and PULL schemes to work together.

This perfectly aligns with the direction we agreed on the previous discussion.
Sounds good and reasonable to me.

> 
> - Added PA-mode detection lag compensation cache (see dedicated section
>   below for design details).

I'm not very sure if this is really needed, though.  I'll leave comment on the
dedicated section below.

> 
> - Added fix for esz=0 quota bypass that allowed unlimited migration when
>   goal was achieved.
> 
> - Added fix for goal_tuner sysfs setting being ignored due to
>   damon_new_scheme() always defaulting to CONSIST.

Thank you for finding and fixing these issues in my previously shared RFC patch
series!  I left a few comments to the patches.  In short, the second fix looks
good and I will add that to the next revision of my RFC patch series, if you
don't mind.  For the first fix, I'd like to take more time on thinking more
cleaner solution.

> 
> - Rebased on SJ's damon/next branch which includes the TEMPORAL goal
>   tuner required for these metrics.

Thank you for clarifying this!  This kind of context is very helpful at
revidewing patches.

> 
> Background and Motivation
> =========================
> 
> In heterogeneous memory systems, controlling hot memory distribution
> across NUMA nodes is essential for performance optimization. This series
> enables system wide hot page distribution with target-state goals like
> "maintain 30% of hot memory on CXL" using PA-mode DAMON schemes.
> 
> Two-Scheme Setup for Hot Page Distribution
> ==========================================
> 
> For maintaining 30% of hot memory on CXL (node 1):
> 
>     PUSH scheme (DRAM->CXL): migrate_hot from node 0 -> node 1
>       goal: node_eligible_mem_bp, nid=1, target=3000
>       Activates when node 1 has less than 30% hot memory
> 
>     PULL scheme (CXL->DRAM): migrate_hot from node 1 -> node 0
>       goal: node_ineligible_mem_bp, nid=1, target=7000
>       Activates when node 1 has more than 30% hot memory
> 
> Both schemes use the TEMPORAL goal tuner which sets esz to maximum when
> under goal and zero when achieved. Together they converge to equilibrium
> at the target distribution.

When this kind of complementary setup is being used, in my opinion, CONSIST
tuner might be better, especially when the access pattern is dynamic.  But it
is up to user's choice.

> 
> What These Metrics Do
> =====================
> 
> node_eligible_mem_bp measures:
>     effective_hot_bytes_on_node / total_hot_bytes * 10000
> 
> node_ineligible_mem_bp measures:
>     (total_hot_bytes - effective_hot_bytes_on_node) / total_hot_bytes * 10000
> 
> The metrics are complementary: eligible_bp + ineligible_bp = 10000 bp.

All make sense to me, so far.

> 
> PA-Mode Detection Lag and Cache Design
> ======================================
> 
> In PA-mode, when pages are migrated:
> 1. Source node detection drops immediately (pages are gone)
> 2. Target node detection increases slowly (new addresses need sampling)

I agree.  And this is not what I clearly expected during the previous
discussion.  Thank you for sharing this issue.

> 
> This asymmetry causes temporary underestimation of hot memory on the
> target node. Without compensation, the system keeps migrating even after
> reaching the goal.

But, is this really significant?  I believe people may use complementary
auto-tune setup especially when they expect dynamic access pattern.  In the
case, even if we can perfectly compensate this kind of gap, some of oscillation
will happen.  You also mentioned "eventual convergence" could be acceptable.

> 
> The cache addresses this by remembering how much was recently migrated.
> When calculating effective hot memory:
> - Source node: reduce detected amount by recent migrations out
> - Target node: boost detected amount by recent migrations in
> 
> The cache uses a rolling window to track migrations over time, and
> expires after a configurable timeout (default 10s) when no migration
> activity occurs. It also detects when its baseline becomes stale due
> to new hot memory appearing in the workload.

I will leave more comments to the patch implementing this.  But this seems too
much at the current stage, unless there are clear test results showing its
needs.  I'd recommend proceeding without this, and later revisit if the problem
becomes clearly significant.

> 
> Dependencies
> ============
> 
> This series is based on SJ's damon/next branch which includes:
> 
> - mm/damon/core: introduce damos_quota_goal_tuner [1]
> - mm/damon/core: set quota-score histogram with core filters [2]
> - mm/damon: always respect min_nr_regions from the beginning [3]
> - mm/damon/core: disallow non-power of two min_region_sz [4]
> 
> [1] https://lore.kernel.org/linux-mm/20260212062314.69961-1-sj@kernel.org/
> [2] https://lore.kernel.org/linux-mm/20260131194145.66286-1-sj@kernel.org/
> [3] https://lore.kernel.org/linux-mm/20260217000400.69056-1-sj@kernel.org/
> [4] https://lore.kernel.org/linux-mm/20260214214124.87689-1-sj@kernel.org/
> 
> Patch Organization
> ==================
> 
> 1. mm/damon/sysfs: set goal_tuner after scheme creation
>     - Fixes goal_tuner initialization order in sysfs scheme creation
> 
> 2. mm/damon: fix esz=0 quota bypass allowing unlimited migration
>     - Ensures esz=0 stops migration rather than bypassing quota entirely
> 
> 3. mm/damon: add node_eligible_mem_bp and node_ineligible_mem_bp goal metrics
>     - Adds the two complementary metrics for hot memory distribution control
> 
> 4. mm/damon: add PA-mode cache for eligible memory detection lag
>     - Implements rolling window cache to compensate for PA-mode detection lag
>     - Adds configurable cache timeout via sysfs
> 
> Testing Status
> ==============
> 
> Functionally tested on a two-node heterogeneous memory system (DRAM + CXL)
> with PUSH+PULL scheme configuration.

Glad to hear the functionality is tested.  Looking forward to the next results!

> 
> This is an RFC and feedback on the design is appreciated.

I'm yet to further reply to the fourth patch, but I hope my comments be worthy
:)


Thanks,
SJ

[...]


      parent reply	other threads:[~2026-02-24  5:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-23 12:32 Ravi Jonnalagadda
2026-02-23 12:32 ` [RFC PATCH v3 1/4] mm/damon/sysfs: set goal_tuner after scheme creation Ravi Jonnalagadda
2026-02-24  1:40   ` SeongJae Park
2026-02-23 12:32 ` [RFC PATCH v3 2/4] mm/damon: fix esz=0 quota bypass allowing unlimited migration Ravi Jonnalagadda
2026-02-24  1:54   ` SeongJae Park
2026-02-23 12:32 ` [RFC PATCH v3 3/4] mm/damon: add node_eligible_mem_bp and node_ineligible_mem_bp goal metrics Ravi Jonnalagadda
2026-02-24  4:27   ` SeongJae Park
2026-02-23 12:32 ` [RFC PATCH v4 4/4] mm/damon: add PA-mode cache for eligible memory detection lag Ravi Jonnalagadda
2026-02-24  5:54   ` SeongJae Park
2026-02-24  5:36 ` 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=20260224053633.58448-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