Summary
Linux 7.2 makes the kernel's Data Access MONitor (DAMON) more relevant to operators of large-memory servers. The release adds a quota goal for controlling how much eligible memory remains on a NUMA node, pause and resume controls, monitoring of data attributes such as anonymous-memory or memory-cgroup membership, and more deterministic quota accounting. Together, these features move DAMON closer to a closed-loop control system for DRAM/CXL placement rather than a collection of static thresholds.
This is not automatic memory-tiering magic. DAMON samples regions rather than tracing every access, its policies can interact with NUMA balancing and reclaim, and the right target depends on whether an application is limited by capacity, bandwidth, latency, or memory pressure. The enterprise opportunity is nevertheless concrete: Linux now exposes better primitives for continuously measuring a workload, applying bounded migration or reclaim actions, and adjusting those actions against an operational goal.
Why Static Tiering Policies Break Down
A two-tier server usually combines relatively fast, scarce DRAM with a larger or differently attached memory tier, often exposed as another NUMA node. CXL can expand capacity, but it does not erase differences in latency and bandwidth. A policy that simply fills DRAM first may leave useful aggregate bandwidth untapped. A policy that interleaves everything evenly may push latency-sensitive pages onto the slower tier. A fixed hotness threshold can work in a benchmark and fail when request mix, model size, cache state, or tenant density changes.
The hard problem is therefore not detecting that two memory classes exist. It is controlling placement while the workload changes. Operators need to answer three questions repeatedly: which regions are active, which regions are eligible for movement, and how aggressively should the system migrate them? Linux already has reclaim, NUMA placement, and automatic tiering mechanisms, but a fleet policy needs observability and bounded actuation as well.
DAMON is designed around that loop. It groups adjacent pages with similar access behavior into regions, samples one page per region, and adaptively splits or merges regions as behavior changes. The number of regions bounds monitoring overhead, while sampling and aggregation intervals determine temporal resolution. DAMON-based Operation Schemes, or DAMOS, can then apply actions such as page-out, LRU prioritization, or migration to regions matching specified size, access-frequency, and age ranges.
What Linux 7.2 Adds
The DAMON maintainer's Linux 7.2 release newsletter identifies seven user-visible additions. Four matter especially for production memory control: the node_eligible_mem_bp goal metric, failed-region quota charge accounting, pause and resume support, and data-attributes monitoring. The release also lets DAMON reclamation monitor all system RAM by default and auto-tune its monitoring intervals.
A Goal for Node-Eligible Memory
The node_eligible_mem_bp metric gives a DAMOS scheme a target expressed in basis points: the proportion of eligible memory associated with a specified NUMA node. The immediate motivation is auto-tuned dynamic interleaving between DRAM and CXL memory. Instead of setting one migration quota and hoping it remains appropriate, a controller can use the observed node distribution as feedback and adjust how much memory the scheme is permitted to move.
This matters because DAMOS quotas are safety controls as well as performance controls. A scheme can be capped by time and bytes per reset interval. DAMON converts those limits to an effective byte quota, then uses a goal tuner to adjust aggressiveness. Linux 7.1 introduced selectable consist and temporal tuning behaviors; Linux 7.2 adds a goal that is directly useful for heterogeneous-memory placement. consist seeks a quota that can be maintained over time, while temporal applies maximum allowed effort until the target is achieved and then drops the quota to zero.
For a long-running database or inference service with shifting working sets, consistent tuning may reduce abrupt migration bursts. For a controlled batch phase, temporal tuning may be preferable because the operator wants to reach a placement target promptly and stop. Neither choice is universally faster. The useful change is that policy intent can be represented separately from the hard quota ceiling.
Better Determinism Around Quotas
Linux 7.2 also introduces a failed-region quota charge ratio. A DAMOS action can fail on a selected region—for example, because pages are not movable or no longer match the effective conditions. Without accounting for failed work, the relationship between a configured quota and actual system effort can be difficult to predict. The new control helps operators decide how failed attempts consume the scheme's budget.
Pause and resume support addresses another operational gap. A DAMON context can now be paused while remaining available for online parameter updates. That is useful during maintenance, benchmark phase changes, or an application rollout where operators want to modify policy without tearing down and rebuilding the monitoring setup. It also makes a user-space controller easier to reason about: configuration and execution can be separated more cleanly.
Attribute Sampling Adds Tenant Context
Data-attributes monitoring extends DAMON beyond access frequency. In Linux 7.2, probes can classify samples using anon and memcg filters. This lets an operator estimate whether a hot or cold region is anonymous memory or belongs to a particular memory cgroup, rather than treating all sampled regions as equivalent.
The distinction is important on shared infrastructure. A system-wide view may show abundant cold memory, but moving or reclaiming it could disproportionately affect one latency-sensitive tenant. Cgroup-aware sampling creates a path toward policies that understand ownership as well as temperature. The kernel documentation is explicit about the trade-off: this is sampling-based and lightweight, so results can contain measurement error. Page-level filtering can provide greater accuracy, but its overhead scales with the amount of memory examined.
DAMON Is a Framework, Not a Finished Tiering Product
Linux 7.2 provides mechanisms, not a universally safe policy. DAMON supports virtual-address, fixed virtual-address, and physical-address operation sets. A policy author still has to choose the target space, define regions and actions, set quotas, and decide which signal represents success. The sysfs interface exposes these controls, but kernel documentation recommends using a user-space tool such as damo rather than manipulating the hierarchy manually.
There are also subsystem interactions to test. DAMON's physical and virtual monitoring can use page-table accessed bits. The documentation notes potential interference with idle-page tracking and describes handling for reclaim interactions. NUMA balancing may independently move pages according to its own observations. Running two controllers with different objectives can create churn: one promotes a region while another later demotes it. Migration traffic itself consumes CPU cycles and memory bandwidth, so a placement policy can degrade the workload it intends to optimize.
CXL adds another source of ambiguity. Capacity expansion, bandwidth aggregation, and cold-page demotion are different objectives. A target ratio that improves a streaming analytics workload may hurt a pointer-heavy database. Hardware topology also matters: NUMA distance alone does not capture every device's latency, bandwidth, switch path, or contention behavior. Infrastructure teams should avoid turning a benchmark-derived percentage into a fleet-wide default.
A Production Evaluation Plan
Establish the Baseline First
Measure the application without active DAMOS actions. Record throughput, tail latency, memory bandwidth, page-fault behavior, NUMA locality, memory-pressure stall information, and migration rates. Capture results over a full workload cycle, not only at peak load. The baseline should include failure conditions such as restart, cache warm-up, compaction, and checkpoint activity.
Next, run DAMON in observation-only mode. Compare its region-level view with application metrics and conventional tools such as numastat, PSI, perf, and cgroup memory counters. The goal is not exact agreement at page granularity; it is to determine whether DAMON's sampled signal is stable enough to drive a policy for this workload.
Add Bounded Actions
Enable migration or reclamation with conservative time and byte quotas. Treat quota ceilings as circuit breakers. Monitor nr_tried, sz_tried, nr_applied, sz_applied, quota exceedances, and failed-charge behavior alongside application service-level indicators. A high attempted-to-applied gap can indicate that filters, eligibility rules, or workload churn are defeating the policy.
Use one operational objective at a time. For tiering, that might be a target fraction of eligible memory on a node. For reclaim, it might be a PSI target. Do not simultaneously optimize node occupancy, free-memory ratio, and tail latency until each individual loop is understood. Multiple plausible goals can still produce an unstable controller.
Validate Isolation and Rollback
Test per-cgroup probes where tenant attribution matters, but remember that sampled attributes are estimates. Verify that a policy cannot move memory outside its intended workload or starve another cgroup. Define a rollback that disables actions immediately, and preserve the baseline configuration. Pause/resume support can help with controlled transitions, but it does not replace a kill switch at the orchestration layer.
Finally, test the kernel and user-space tooling versions that will run in production. DAMON has evolved quickly across recent kernels, and configuration files or scripts should not assume that every distribution exposes the same features or enables the required kernel options.
What This Means for Infrastructure Teams
The notable change in Linux 7.2 is not one new CXL optimization. It is the shape of the control surface. DAMON can observe access patterns and selected data attributes, constrain actions by explicit budgets, accept feedback goals, and pause while policy is updated. Those capabilities are the components of an operational control loop.
For server architects, this makes software-defined memory placement more credible. Hardware capacity can be purchased in tiers, while policy decides how much of the workload receives the fastest tier at a given time. For platform teams, cgroup-aware sampling offers a route toward tenant-sensitive memory management. For performance engineers, the new controls make experiments more repeatable because action budgets and target metrics are visible rather than hidden in a one-off daemon.
The cautious conclusion is that DAMON is becoming deployable infrastructure, not that heterogeneous memory has become self-managing. Production success will depend on workload-specific objectives, bounded migration, kernel-version discipline, and continuous measurement. Linux 7.2 supplies stronger primitives for that work—and makes DRAM/CXL tiering look less like static NUMA configuration and more like a feedback-control problem.