This series introduces a new DAMON quota goal metric, `node_target_mem_bp`,
designed for controlling memory migration in heterogeneous memory systems
(e.g., DRAM and CXL memory tiering).

v1: https://lore.kernel.org/linux-mm/20260123045733.6954-1-ravis.opensrc@gmail.com/T/#u

Changes since v1:
=================

- Renamed metric from `node_sys_bp` to `node_target_mem_bp` for consistency
  with existing node-related quota goal metrics (node_mem_used_bp,
  node_mem_free_bp) as suggested by SJ.

- Fixed the metric calculation:
  * Numerator: Now correctly counts only scheme-eligible bytes (regions
    matching the scheme's access pattern criteria).
  * Denominator: Now uses node capacity instead of total system memory.

- Removed the get_goal_metric() ops callback. The implementation now
  resides in core.c, following the existing pattern for other metrics
  that have ops-layer dependencies.

- Removed the early-exit optimization patch. As SJ noted, this would
  introduce a behavioral change for existing users and should be an
  opt-in feature with a properly designed interface. This can be
  addressed in a separate follow-up series.

- Removed capacity clamping logic (was tied to early-exit behavior).

Background and Motivation
=========================

A previous patch series [1] added weighted interleave support for DAMON
migrate_{hot,cold} actions for vaddr schemes. That approach requires VMA
offset information to determine target nodes, which for paddr schemes
would require costly rmap walks.

This series takes a different approach for PA-based migration control
using basis points (bp) target-state goals instead of weight-based
action rates, avoiding the need for rmap walks entirely.

What This Metric Does
=====================

The `node_target_mem_bp` metric measures:

    scheme_eligible_bytes_on_node / node_capacity

expressed in basis points (bp, 1/10000).

"Scheme-eligible bytes" are regions that match the scheme's access pattern
criteria (size, nr_accesses, age). This allows users to specify goals like:

    "Migrate hot pages until node N contains X% hot memory"

Unlike weight-based approaches that specify ACTION RATES, this metric
specifies a TARGET STATE, which naturally prevents oscillation issues
that would occur with weight-based PA migration without rmap.

Two-Context Setup for Hot Page Distribution
===========================================

For distributing hot pages between two NUMA nodes (e.g., DRAM node 0 and
CXL node 1), two DAMON contexts work together:

    Context 0: monitors node 0, migrate_hot -> node 1
      goal: node_target_mem_bp, nid=0, target=6000
      "Migrate hot pages out when node 0 exceeds 60% hot"

    Context 1: monitors node 1, migrate_hot -> node 0
      goal: node_target_mem_bp, nid=1, target=4000
      "Migrate hot pages out when node 1 exceeds 40% hot"

Each context migrates excess hot pages to the other node. The system
converges when both nodes reach their target hot memory ratios.

Complementary to Existing vaddr Migration
=========================================

This series complements rather than replaces the vaddr weighted interleave
migration:

  vaddr migration (weight-based):
    - Per-process control
    - Fine-grained interleave patterns via VMA offset
    - Deterministic placement based on weights

  paddr migration (bp-based, this series):
    - System-wide control
    - Target-state goals for node capacity management
    - No rmap overhead

Patch Organization
==================

1. mm/damon/core: add DAMOS_QUOTA_NODE_TARGET_MEM_BP metric
   - Adds new enum value and documentation

2. mm/damon/core: implement NODE_TARGET_MEM_BP metric calculation
   - Adds damos_get_node_target_mem_bp() function
   - Updates function signatures to pass ctx and scheme through call chain

3. mm/damon/sysfs-schemes: expose NODE_TARGET_MEM_BP metric
   - Exposes metric as 'node_target_mem_bp' in sysfs

Status
======

These patches have been compile-tested but have NOT been tested on actual
hardware. Feedback on the design and approach is appreciated.

References
==========

[1] mm/damon/vaddr: Allow interleaving in migrate_{hot,cold} actions
    https://lore.kernel.org/linux-mm/20250709005952.17776-1-bijan311@gmail.com/

Ravi Jonnalagadda (3):
  mm/damon/core: add DAMOS_QUOTA_NODE_TARGET_MEM_BP metric
  mm/damon/core: implement NODE_TARGET_MEM_BP metric calculation
  mm/damon/sysfs-schemes: expose NODE_TARGET_MEM_BP metric

 include/linux/damon.h    |  5 +++
 mm/damon/core.c          | 66 +++++++++++++++++++++++++++++++++++-----
 mm/damon/sysfs-schemes.c |  5 +++
 3 files changed, 69 insertions(+), 7 deletions(-)

-- 
2.43.0

On Thu, 29 Jan 2026 13:58:11 -0800 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:

> This series introduces a new DAMON quota goal metric, `node_target_mem_bp`,
> designed for controlling memory migration in heterogeneous memory systems
> (e.g., DRAM and CXL memory tiering).
> 
> v1: https://lore.kernel.org/linux-mm/20260123045733.6954-1-ravis.opensrc@gmail.com/T/#u
> 
[...]
> Two-Context Setup for Hot Page Distribution
> ===========================================
> 
> For distributing hot pages between two NUMA nodes (e.g., DRAM node 0 and
> CXL node 1), two DAMON contexts work together:
> 
>     Context 0: monitors node 0, migrate_hot -> node 1
>       goal: node_target_mem_bp, nid=0, target=6000
>       "Migrate hot pages out when node 0 exceeds 60% hot"
> 
>     Context 1: monitors node 1, migrate_hot -> node 0
>       goal: node_target_mem_bp, nid=1, target=4000
>       "Migrate hot pages out when node 1 exceeds 40% hot"
> 
> Each context migrates excess hot pages to the other node. The system
> converges when both nodes reach their target hot memory ratios.

Thank you for adding this example use case!  This is very helpful for
understanding how people can use this feature, and if there is a wrong
assumption.

I think the use case idea is nice and making sense to me.  Nonetheless, I find
a DAMON's devil in the detail.

DAMOS quota autotuning assumes applying the given scheme action more
aggressively (increasing quota) will help increasing the quota goal metric.  In
other words, it believes the aggressiveness (tuned quota size) and the metric
value are proportional.  Hence, for the first context, DAMON will migrate hot
pages of node 0 to node 1, when the hot pages in node 0 is less than 60%, and
start gradually decreasing and eventually stop the migration after hot memory
portion on node 0 reaches and exceeds 60%.  A human readable interpretation of
it would be, "Migrate hot pages out when node 0 not exceeds 60% hot", which
makes no sense for your use case.

To make it work as you described, you may implement another metric representing
the ratio of scheme-uneligible memory on the given node.  Say,
'node_ineligible_mem_bp'?  To borrow your above nice notation, it could be
calculated as below:

    (node_capacity - scheme_eligible_bytes_on_node) / node_capacity

Using this, your above use case could implemented like below:

    Context 0: monitors node 0, migrate_hot -> node 1
      goal: node_ineligible_mem_bp, nid=0, target=4000

    Context 1: monitors node 1, migrate_hot -> node 0
      goal: node_ineligible_mem_bp, nid=1, target=6000

And I'm not very sure if that is really what you want.  For example, if node 0
has 30% hot memory and node 1 has 20% hot memory, no migration will happen.

I think you might want node 0 to have more hot memory, but no more than 60% of
the node.  DAMON-based auto-tuned memory tiering [1], for example, use this
kind of approach.  If that's what you want, you could use node_target_mem_bp
together, like below.

    Context 0: monitors node 0, migrate_hot -> node 1
      goal: node_ineligible_mem_bp, nid=0, target=4000

    Context 1: monitors node 1, migrate_hot -> node 0
      goal: node_target_mem_bp, nid=0, target=6000

I'm not still very confident if I understand what you want, because you
mentioned dynamic weighted interleaving was the major motivation of this
project.  In the case, you might want only hot memory be distributed across
NUMA nodes in a specific ratio.  In the case, you may want the denominator be
"scheme-eligible memory of the system" instead of "node capacity".  To borrow
your notation again,

    scheme_eligible_bytes_on_node / scheme_eligible_bytes_on_system

Let's call this just node_target_mem_bp2.  Then, if you want node 0 and 1 to
have 60% and 40% of hot memory, you could setup DAMOS as below:

    Context 0: monitors node 0, migrate_hot -> node 1
      goal: node_target_mem_bp2, nid=1, target=4000

    Context 1: monitors node 1, migrate_hot -> node 0
      goal: node_target_mem_bp2, nid=0, target=6000

[...]
> Status
> ======
> 
> These patches have been compile-tested but have NOT been tested on actual
> hardware.

It will be very helpful!

> Feedback on the design and approach is appreciated.

So you might need to change the definition and name of the metric, and/or add
new metrics.  But the basic theory of the requirements, the design and the
implementation approach of this patch series looks good to me!

> 
> References
> ==========
> 
> [1] mm/damon/vaddr: Allow interleaving in migrate_{hot,cold} actions
>     https://lore.kernel.org/linux-mm/20250709005952.17776-1-bijan311@gmail.com/

[1] https://github.com/damonitor/damo/blob/next/scripts/mem_tier.sh


Thanks,
SJ

[...]

On Thu, 29 Jan 2026 17:48:06 -0800 SeongJae Park <sj@kernel.org> wrote:

> On Thu, 29 Jan 2026 13:58:11 -0800 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:
> 
> > This series introduces a new DAMON quota goal metric, `node_target_mem_bp`,
> > designed for controlling memory migration in heterogeneous memory systems
> > (e.g., DRAM and CXL memory tiering).
> > 
> > v1: https://lore.kernel.org/linux-mm/20260123045733.6954-1-ravis.opensrc@gmail.com/T/#u
[...]
>     Context 0: monitors node 0, migrate_hot -> node 1
>       goal: node_ineligible_mem_bp, nid=0, target=4000
> 
>     Context 1: monitors node 1, migrate_hot -> node 0
>       goal: node_target_mem_bp, nid=0, target=6000

In offline, Ravi enlightened me that using a single context with two schemes
instead of the above two contexts setup can be more efficienct and useful.  I
agree that.  It will be able to only single kdamond, and there could be more
flexible use cases that can use the whole-memory access pattern.

That is, we can use single context with the two schemes, but adding a core
layer DAMOS filters for applying the schemes to only memory of node 0 and node
1, respectively.  Similar for memory tiering use cases.

But I was recommending the multi contexts approach to people because the
current implementation of DAMOS is not efficient when both quota and core layer
filters are used.  I was actually working on making it improved, and just
posted an RFC patch series [1].  After the patches are merged, hopefully the
single context approach will be useful and effcient enough for varying use
cases including the memory tiering.

[1] https://lore.kernel.org/20260131194145.66286-1-sj@kernel.org


Thanks,
SJ

[...]

On Sat, Jan 31, 2026 at 11:54 AM SeongJae Park <sj@kernel.org> wrote:
>
> On Thu, 29 Jan 2026 17:48:06 -0800 SeongJae Park <sj@kernel.org> wrote:
>
> > On Thu, 29 Jan 2026 13:58:11 -0800 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:
> >
> > > This series introduces a new DAMON quota goal metric, `node_target_mem_bp`,
> > > designed for controlling memory migration in heterogeneous memory systems
> > > (e.g., DRAM and CXL memory tiering).
> > >
> > > v1: https://lore.kernel.org/linux-mm/20260123045733.6954-1-ravis.opensrc@gmail.com/T/#u
> [...]
> >     Context 0: monitors node 0, migrate_hot -> node 1
> >       goal: node_ineligible_mem_bp, nid=0, target=4000
> >
> >     Context 1: monitors node 1, migrate_hot -> node 0
> >       goal: node_target_mem_bp, nid=0, target=6000
>
> In offline, Ravi enlightened me that using a single context with two schemes
> instead of the above two contexts setup can be more efficienct and useful.  I
> agree that.  It will be able to only single kdamond, and there could be more
> flexible use cases that can use the whole-memory access pattern.
>
> That is, we can use single context with the two schemes, but adding a core
> layer DAMOS filters for applying the schemes to only memory of node 0 and node
> 1, respectively.  Similar for memory tiering use cases.
>
> But I was recommending the multi contexts approach to people because the
> current implementation of DAMOS is not efficient when both quota and core layer
> filters are used.  I was actually working on making it improved, and just
> posted an RFC patch series [1].  After the patches are merged, hopefully the
> single context approach will be useful and effcient enough for varying use
> cases including the memory tiering.
>
> [1] https://lore.kernel.org/20260131194145.66286-1-sj@kernel.org
>
Thanks for providing the DAMOS_FILTER patch update SJ.

For v3, I plan to introduce two complementary metrics:
DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP
and DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP.

This will support the following approaches for hot memory migration:
1. Single context with two schemes using both metrics.
(along with DAMOS_FILTER_TYPE_ADDR)
2. Two DAMON contexts each using
DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP.

Will provide more details on the implementation and usage in the v3 series.

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

On Tue, 3 Feb 2026 11:48:06 -0800 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:

> On Sat, Jan 31, 2026 at 11:54 AM SeongJae Park <sj@kernel.org> wrote:
> >
> > On Thu, 29 Jan 2026 17:48:06 -0800 SeongJae Park <sj@kernel.org> wrote:
> >
> > > On Thu, 29 Jan 2026 13:58:11 -0800 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:
> > >
> > > > This series introduces a new DAMON quota goal metric, `node_target_mem_bp`,
> > > > designed for controlling memory migration in heterogeneous memory systems
> > > > (e.g., DRAM and CXL memory tiering).
> > > >
> > > > v1: https://lore.kernel.org/linux-mm/20260123045733.6954-1-ravis.opensrc@gmail.com/T/#u
> > [...]
> > >     Context 0: monitors node 0, migrate_hot -> node 1
> > >       goal: node_ineligible_mem_bp, nid=0, target=4000
> > >
> > >     Context 1: monitors node 1, migrate_hot -> node 0
> > >       goal: node_target_mem_bp, nid=0, target=6000
> >
> > In offline, Ravi enlightened me that using a single context with two schemes
> > instead of the above two contexts setup can be more efficienct and useful.  I
> > agree that.  It will be able to only single kdamond, and there could be more
> > flexible use cases that can use the whole-memory access pattern.
> >
> > That is, we can use single context with the two schemes, but adding a core
> > layer DAMOS filters for applying the schemes to only memory of node 0 and node
> > 1, respectively.  Similar for memory tiering use cases.
> >
> > But I was recommending the multi contexts approach to people because the
> > current implementation of DAMOS is not efficient when both quota and core layer
> > filters are used.  I was actually working on making it improved, and just
> > posted an RFC patch series [1].  After the patches are merged, hopefully the
> > single context approach will be useful and effcient enough for varying use
> > cases including the memory tiering.
> >
> > [1] https://lore.kernel.org/20260131194145.66286-1-sj@kernel.org
> >
> Thanks for providing the DAMOS_FILTER patch update SJ.
> 
> For v3, I plan to introduce two complementary metrics:
> DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP
> and DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP.
> 
> This will support the following approaches for hot memory migration:
> 1. Single context with two schemes using both metrics.
> (along with DAMOS_FILTER_TYPE_ADDR)
> 2. Two DAMON contexts each using
> DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP.

Sounds good!

> 
> Will provide more details on the implementation and usage in the v3 series.

Looking forward to it!


Thanks,
SJ

[...]