RFC mm/damon: Introduce node_target_mem_bp Quota Goal Metric
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 RFC Latest3 patches 5 repliesIn review
- v1 RFC5 patches 7 repliesSuperseded
Changes in v2 from the cover letter
=================
- 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).
Patches in v2 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | mm/damon/core: add DAMOS_QUOTA_NODE_TARGET_MEM_BP metricinclude/ | +5 | 1 reply | |
| 2/3 | mm/damon/core: implement NODE_TARGET_MEM_BP metric calculationmm/ | +59 | 0 replies | |
| 3/3 | mm/damon/sysfs-schemes: expose NODE_TARGET_MEM_BP metricmm/ | +5 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [RFC PATCH v2 0/3] mm/damon: Introduce node_target_mem_bp Quota Goal Metric
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/[email protected]/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/[email protected]/
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(-)
Signature · 1 line
2.43.0