Re: [RFC PATCH v3 0/4] mm/damon: Introduce node_eligible_mem_bp and node_ineligible_mem_bp Quota Goal Metrics

[Ravi Jonnalagadda <ravis.opensrc@gmail.com>]

On Mon, Feb 23, 2026 at 9:36 PM SeongJae Park <sj@kernel.org> wrote:
>
> 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 :)

Thank you for the detailed review!

>
> >
> > 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.

Great, glad the approach makes sense.

>
> >
> > - 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.

Understood. I consciously separated the cache implementation (patch 4)
from the core metrics (patch 3) because the cache is ONE possible approach to
handle detection lag - not necessarily THE approach. My goal was to share
what was needed to achieve equilibrium with my synthetic benchmark
workload (multiload),
while making it clear that the cache mechanism could be dropped or
replaced with alternatives.

>
> >
> > - 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.

Sounds good. Please go ahead and incorporate the goal_tuner fix into
your series.
Happy to test whatever approach you come up with for the esz=0 issue.

>
> >
> > - 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.
>

That's a fair point. I chose TEMPORAL because I wanted to move the required
amount of pages as quickly as possible to reach equilibrium.
For my multiload benchmark with uniformly hot memory, this seemed like the
most direct approach to test the metrics.

> >
> > 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.

I'm glad this observation is useful. It was something I discovered during
testing that wasn't obvious until I looked at the trace data closely.

>
> >
> > 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.
>

This is a valid point. Real-world workloads with mixed hot/cold memory and
dynamic access patterns might behave differently from my synthetic benchmark
where all memory is uniformly hot. The uniform-hot case is essentially a
worst-case scenario that forces continuous oscillation regardless of
detection lag compensation.

For my multiload workload without patch 4, there was significant unnecessary
page movement due to the detection lag. However, as you note, that may be an
artifact of the synthetic benchmark + TEMPORAL tuner combination rather than
a fundamental problem that affects all use cases.

> >
> > 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.

I agree. Let's drop patch 4 for now and focus on getting the core
metrics merged.
The cache mechanism can be revisited later if real-world usage shows
it's needed.

>
> >
> > 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
> :)
>

Very much so! Your feedback has been invaluable in shaping this work. :-)

I'm currently on a break and will be back after March 10th. Once I return,
I'll send the updated patch 3 and share test results with CONSIST
tuner.

Thanks again for the thorough review!

Ravi
>
> Thanks,
> SJ
>
> [...]