MANTA: Machine Learning Augmented Tiering Advisor

Johannes Freischuetz

Kiet Pham

Sujay Yadalam

freischuetz@cs.wisc.edu University of Wisconsin – Madison Madison, Wisconsin, USA

kvpham@wisc.edu University of Wisconsin – Madison Madison, Wisconsin, USA

sujay@cs.utexas.edu University of Texas at Austin Austin, Texas, USA

Konstantinos Kanellis∗

Michael Swift

Shivaram Venkataraman

kkanelli@amazon.com Amazon Web Services New York, New York, USA

swift@cs.wisc.edu University of Wisconsin – Madison Madison, Wisconsin, USA

shivaram@cs.wisc.edu University of Wisconsin – Madison, ETH Zurich Zurich, Switzerland

CCS Concepts: • Software and its engineering → Memory management; • Computing methodologies → Supervised learning. Keywords: Memory Tiering, CXL Memory, ML for Systems ACM Reference Format: Johannes Freischuetz, Kiet Pham, Sujay Yadalam, Konstantinos Kanellis, Michael Swift, and Shivaram Venkataraman. 2027. MANTA: Machine Learning Augmented Tiering Advisor. In 22nd European Conference on Computer Systems (EuroSys ’27), April 19-23, 2027, Rabat, Morocco. ACM, New York, NY, USA, 17 pages. https://doi. org/10.1145/3842654.3848563 ∗ This work was conducted while at the University of Wisconsin – Madison.

This work is licensed under a Creative Commons Attribution 4.0 International License. EuroSys ’27, Rabat, Morocco © 2027 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2971-3/2027/04 https://doi.org/10.1145/3842654.3848563

Virtual Addresses

20

10

Time (Seconds)

(a) BC-Kron access heatmap. The highlighted interval is enlarged at right.

100

90

80

70

60

50

122

100

75

50

0

25

Memory tiering has been used to expand memory capacity, particularly in datacenters, by combining fast DRAM with slower tiers, including CXL-attached memory. Its effectiveness depends on keeping useful pages in the fast tier, but existing heuristic policies can lag behind changing hot sets in phased or bursty workloads. To explore these limitations, we introduce ChOMP, a scalable offline optimizer that minimizes placement and bandwidth-sensitive migration costs. We then develop a trace-driven simulator that uses this reference to identify performance opportunities for online policies. Motivated by these results, MANTA predicts future page usefulness from runtime access features and integrates a lightweight learned model into ARMS. Across eight workloads on emulated CXL, MANTA achieves geometric-mean speedups over ARMS of 1.12× and 1.08× at 4 GB of fast memory on Linux 6.2 and 6.18, respectively; across six Optane workloads, it achieves 1.69×. On individual workloads, MANTA is up to 1.25× faster than ARMS with emulated CXL on Linux 6.2, 1.21× on Linux 6.18, and 5.6× with Optane.

Virtual Addresses

30

Abstract

0

arXiv:2610.00714v1 [cs.DC] 30 Sep 2026

MANTA: Machine Learning Augmented Tiering Advisor

Time (Seconds)

(b) Approximate ARMS placement with 4 GB of fast memory.

Figure 1. Access intensity for BC-Kron on the left, with approximate page placements on the right. Delayed migrations cause much of the benefit to be missed.

1

Introduction

Memory is an increasing fraction of datacenter cost [28, 43], motivating tiered deployments that combine fast local DRAM with larger, cheaper CXL or persistent memory [7, 10, 25, 50, 51]. We refer to local DRAM as the fast tier and CXL or persistent memory as the slow tier. Reported CXL latencies are often 200–300 ns versus roughly 100 ns for DRAM, with Optane slower still [18, 26, 46]. Effective tiering must keep useful pages in fast memory [44] while deciding when migration benefits outweigh copying costs and bandwidth contention. A page must remain useful long enough for its fast-memory accesses to repay the cost of moving it. Migration timing also matters because copying pages competes with the application for bandwidth. Existing systems [2, 24, 27, 28, 35, 47–49] use heuristics based on recency, frequency, page age, or bandwidth pressure [42]. These policies are reactive, promoting or demoting pages when recent behavior crosses a threshold. Access history often suffices for stable workloads [45, 47], but phased or bursty workloads can change hot sets faster than policies adapt. Slow reactions leave useful data in the slow tier or waste scarce fast-tier capacity on stale hot pages. Figure 1 illustrates the problem on Betweenness Centrality (BC) over the Kron graph (BC-Kron). ARMS [48] retains pages from the previous hot phase while currently useful pages remain in slow memory. Much of the benefit is lost

EuroSys ’27, April 19-23, 2027, Rabat, Morocco

because the hot set changes again almost immediately after migration. To systematically characterize these missed opportunities, we compare online policies with an offline reference that knows the entire access trace. An offline reference can expose missed opportunities even when several online policies make similar placement mistakes. Existing offline formulations [53] have two limitations: solving a 10-second trace with around a billion accesses takes more than 60 hours, and fixed migration penalties ignore contention with concurrent memory traffic [18]. We develop ChOMP, a Chunked Offline Memory Policy, that aggregates accesses within intervals and accounts for bandwidth-sensitive migration costs. It minimizes migration costs minus fast-memory access savings among schedules that migrate at interval boundaries. ChOMP solves traces up to 630× longer than CHOPT in a similar time. The resulting schedule gives us concrete placements and migration times to compare with online policies. To evaluate this offline schedule, we build a trace-driven simulator calibrated against measured runtimes (Section 3.2). For BC-Kron with 2 GB of fast memory, MANTA reduces measured runtime from 241.3 s with ARMS to 221.3 s, a 1.09× speedup (Figure 13a). Comparing these measurements with the simulated ChOMP reference shows that MANTA closes much of the gap while leaving room for further gains (Section 5.5). The remaining gap exposes a timing problem: late promotions and demotions lose performance when a policy recognizes a page’s usefulness only after its accesses occur (Section 3.2). Recurring access patterns provide a way to anticipate that usefulness from information available at runtime. MANTA predicts a page’s discounted future-access count, giving greater weight to nearer accesses (Equation 1). Its model combines recent activity, longer-term history, and spatial context, learning how these signals interact for each application so it can identify useful pages before reactive hotness scores catch up. We integrate these predictions into ARMS’s periodic tiering loop, retaining its access tracking, migration execution, and capacity management. We target recurring, profileable applications, training application-specific models on prior runs. MANTA makes its predictions using a lightweight tree model compiled to native code, with features commonly used in prior work. We introduce sample-based virtual time steps to make these features less sensitive to execution speed. The compiled model scores more than 10,000 pages in under 20 ms. We evaluate MANTA across emulated CXL and Optane, eight workloads, and two Linux kernels, comparing with ARMS, HybridTier, NOMAD, TPP, and Memtis [24, 28, 37, 45, 48]. At 4 GB of fast memory, geometric-mean speedups over ARMS are 1.12× on Linux 6.2, 1.08× on Linux 6.18, and 1.69× across six Optane workloads. Across evaluated workloads and capacities, maximum speedups over ARMS are approximately 1.25× on Linux 6.2, 1.21× on Linux 6.18, and 5.6× on Optane. On Linux 6.2, MANTA has the highest geometric-mean

Johannes Freischuetz et al.

speedup at every capacity, outperforming Memtis by 1.28× at 4 GB and 1.03–1.11× at larger capacities.

2

Background

Earlier work explored page placement and data tiering in heterogeneous memory systems [2, 16, 34, 49]. Online tiered-memory systems use observed page accesses to decide which pages to promote to fast memory and which to demote to slow memory. Systems such as TPP [28], ARMS [48], HybridTier [37], NOMAD [45], and HeMem [35] combine lowoverhead tracking with heuristic estimates of page hotness. Colloid [42] also incorporates contention and latency measurements into placement decisions. These policies use recent measured behavior to guide future placement, making hotness estimation a common component despite differences in tracking and migration mechanisms. Mira [19] takes a complementary approach through program-guided slowmemory management rather than transparent page tiering. Tiered-memory policies differ in the signals they use, where their decisions execute, and the granularity at which they manage memory. Table 1 summarizes these differences for the systems most closely related to MANTA. Learning-based policies explore alternatives to heuristic hotness estimation. Kleio, Coeus, and Cronus use learned access predictions or select pages and page groups for learned management [11–13]. These works primarily explore prediction in offline or simulator-driven settings, with inference costs posing a challenge for an online policy deployment. Other learning-based approaches act on different decisions: IDT and ArtMem use reinforcement learning to tune demotion policies or migration scope [9, 52], while Learning-to-Rank predicts an offline ranking of application objects for static placement without migration [29]. Table 1 contrasts direct prediction of future page usefulness with heuristic tuning and static object placement. MANTA combines direct page-level prediction with online execution and dynamic migration. It predicts a lightweight discounted future-usefulness score that can replace the hotness estimate in an existing ranking-based policy, while the surrounding system continues to handle the migration mechanism. This integration requires scoring pages quickly enough to fit within the existing periodic tiering loop. Migration timing is a complementary policy decision: Cori [14] uses application data-reuse information to tune the frequency of data movement across memory tiers. To put these online placement and migration decisions in context, we consider policies that know the full access trace. Belady’s MIN is the classical offline benchmark for single-tier caching, giving the optimal eviction rule [5]. Prior work develops practical bounds on optimal caching for variable-size objects [6]. Learning Relaxed Belady shows how oracle-style caching can be approximated in other domains such as CDN

MANTA : Machine Learning Augmented Tiering Advisor

EuroSys ’27, April 19-23, 2027, Rabat, Morocco MLBased

Direct Hotness Prediction

Online System

Dynamic Migration

Recent access frequency and age Hotness class and page size Recent page hotness Access-frequency hotness Adaptive page-hotness score

✗ ✗ ✗ ✗ ✗

✗ ✗ ✗ ✗ ✗

✓ ✓ ✓ ✓ ✓

✓ ✓ ✓ ✓ ✓

Pages Pages Pages Pages Pages

Kleio [11] Coeus [12] Cronus [13] Cori [14] Learning-to-Rank [29] IDT [9] ArtMem [52]

Next-epoch page accesses Page-group access patterns Groups for learned page management Migration cadence Object performance rank Demotion-policy parameters Hotness threshold and migration scope

✓ ✓ ✓ ✗ ✓ ✓ ✓

✓ ✓ ✓ ✗ ✗ ✗ ✗

✗ ✗ ✗ ✗ ✗ ✓ ✓

✓ ✓ ✓ ✓ ✗ ✓ ✓

Selected Pages Selected Page Groups Selected Page Groups System-wide knob Objects Heuristic Knobs Heuristic Knobs

MANTA

Discounted future page usefulness

✓

✓

✓

✓

Pages

System

Decision/Output

TPP [28] Memtis [24] NOMAD [45] HybridTier [37] ARMS [48]

Decision Granularity

Table 1. Memory-tiering approaches. Direct hotness prediction estimates future page usefulness. Online policies run during application execution, as opposed to in a simulator. Dynamic migration moves pages between tiers online.

A

B

A

B

A

C

C

A

B

A

B

A

C

C

Step 2 Step 3 Step 1 Figure 2. CHOPT’s access graph [53] with ChOMP’s time steps (blue boxes). Green edges represent retained pages, orange upward and purple downward edges represent promotions and demotions, respectively. Aggregating repeated accesses removes intermediate migration choices (dashed edges). caches [38]. For tiered memory, CHOPT formulates offlineoptimal placement across heterogeneous cache, memory, and storage tiers with asymmetric access costs, and uses sampling to approximate longer traces [53]. Section 3 examines the limitations of these approaches for interval-based page migration and motivates a reference policy that accounts for migration interference and bandwidth contention.

3

Characterizing the Limits of Heuristic Tiering Policies

A useful way to understand the limitations of online tiering policies is to compare them with an offline policy that has full knowledge of the trace. Classical offline caching policies, such as Belady’s MIN [5], however, are insufficient for tiered memory because they ignore migration costs and bandwidth contention [42]. A Belady-style policy can migrate too aggressively in a tiered-memory system [53]. It also ignores the potential benefit of distributing accesses across tiers when one memory link approaches saturation. The state-of-the-art offline policy for tiered memory is CHOPT [53]; Figure 2 shows its access-level graph with our time-step grouping overlaid. CHOPT formulates placement as a min-cost-flow problem in which each unit of flow represents one unit of fast-memory capacity. A flow through

the graph selects which pages occupy fast memory over the access trace, while edge costs encode fast-memory benefits and migration penalties. Here, an optimal policy is a placement and migration schedule that minimizes total modeled cost over the trace among schedules that satisfy the capacity and migration constraints in CHOPT’s formulation. This formulation is powerful because it can recover the optimal migration decisions for a trace under its cost model. It has two limitations for our setting. First, solving its accesslevel formulation is prohibitively expensive for our full traces, which can contain tens or hundreds of billions of accesses. For 𝑛 accesses, CHOPT’s two-tier graph contains 2𝑛 + 2 nodes and up to 4𝑛 + 2 edges. Constructing and storing the graph grows with the number of accesses rather than the number of distinct pages [53]. Prior CHOPT evaluations use spatial sampling to reduce the traces solved to around 10 million accesses [53]. Scaling this up to a billion sampled accesses, or a 10 second trace, increases the solution time to around 60 hours, as shown in Figure 3. Second, CHOPT models migration costs as a constant without considering ongoing migrations or concurrent memory traffic. That simplification does not hold in practical tiered-memory systems [39, 42, 48]. CHOPT also restricts migrations to occur immediately before an access. In real systems, migrations can block concurrent accesses to the page: if a write arrives during migration, it must wait until the copy completes [35]. Allowing earlier promotions would let the offline policy move pages before they are needed. Migrations also interact with demand accesses through bandwidth contention [18]. A migration during an idle period can be relatively cheap, while the same migration during a memory-intensive phase can stall the application by competing for bandwidth. The cost of a migration therefore depends on what other accesses and migrations occur nearby in time, so temporally clustered migrations should incur increasing penalties.

Together, these observations point to a gap in characterizing the limits of tiering policies. This section addresses this gap in three steps: we design an interval-constrained offlineoptimal policy under a bandwidth-sensitive migration-cost model, use that policy with a simulator to measure where existing online heuristics fall short, and use those results to motivate a learned online policy. 3.1

ChOMP Interval-Constrained Offline-Optimal Policy

We design Chunked Offline Memory Policy, or ChOMP, around fixed time steps. Many modern tiering systems already batch measurements and perform migrations periodically [27, 35, 37, 42, 48]. Restricting placement decisions to these intervals lets us compress CHOPT’s access-level graph and makes room for two extensions: early migrations and bandwidth-sensitive migration costs. Time-Step Aggregation. The blue boxes in Figure 2 illustrate how we group the access trace into time steps. Within each step, we combine repeated accesses to a page into one placement decision, weighted by the total savings from serving those accesses in fast memory. Because migrations occur only between steps, the two accesses to A in step 2 share one placement decision, as do the two accesses to C in step 3. The dashed edges mark intermediate migration choices that disappear with this aggregation. The resulting graph represents pages across time steps rather than individual accesses, greatly reducing its size on traces with many repeated accesses. As in CHOPT, each unit of flow represents one page of fast-memory capacity; the selected flow determines which pages occupy that capacity over time. Bandwidth-Sensitive Migration Costs. The smaller graph gives us the computational budget to encode more accurate costs and migration decisions. We encode migration interference during graph construction. For each step, we estimate the bandwidth consumed by application accesses and use the bandwidth/latency profiles supplied by MESS [18] to determine the cost of adding migration traffic. In addition to fixed migration overheads, such as page-table updates, we encode a shared piecewise-linear interference cost for migrations at that step’s boundary. Its segments have increasing marginal costs: as more pages migrate in the same step, each additional migration becomes more expensive, especially when application traffic already approaches the bandwidth limit. With these costs encoded before solving, the optimizer balances a page’s future access savings against its migration timing and the number of migrations in that step. Early Migrations. We also allow migrations to occur in steps where the page is not directly accessed. This allows ChOMP to migrate pages during an idle step to minimize migration costs during busier steps, while still receiving the full access benefit when the page is eventually accessed. In the example, C is first accessed in step 3, but ChOMP can choose to promote it in step 2 if bandwidth and fast-memory capacity

Johannes Freischuetz et al.

Time (Hours)

EuroSys ’27, April 19-23, 2027, Rabat, Morocco 60 40

Model CHOPT CHOPT Pruned ChOMP

21x

20 0

215

217

219

221

223

225

227

Memory Trace Length

Figure 3. Solver time versus trace length for CHOPT, CHOPT++, and our policy, ChOMP. are available. We also allow the model to select the initial and final placements of pages in fast memory, including an ideal initial placement. Given the trace, fast-memory capacity, and these costs, ChOMP jointly selects placements and migrations across the full trace to minimize migration costs minus fast-memory access savings. The resulting schedule is optimal within the aggregated-access and migration-cost model, with migrations restricted to interval boundaries; aggregation discards intra-interval access ordering. We replay this schedule in the simulator to compare it with practical tiering policies. Model Optimizations. We further reduce the graph without changing its optimal solution by pruning migration choices whose future access savings cannot amortize their costs, removing disconnected nodes, and contracting nodes with only one incoming and one outgoing edge. We then express the graph as a linear program, replacing all flow structures with equivalent constraints. While the formulation is a linear program, it retains an integral optimum through total unimodularity [21]. Applying these same optimizations to CHOPT gives CHOPT++, which supports approximately 21× longer traces than unoptimized CHOPT but retains accesslevel decisions. ChOMP’s additional scalability comes from time-step aggregation; the smaller graph does not imply solver time is linear in the number of steps. We solve the linear program using the Gurobi solver [20]. Our optimizations substantially reduce solver time, and Figure 3 shows the resulting speedups. Relative to an unoptimized CHOPT formulation, ChOMP can solve traces that are up to 630× longer, or 32× longer than our CHOPT++ implementation. This lets ChOMP solve traces longer than 10 minutes, sufficient for our evaluation workloads, in about 30 minutes. Unoptimized CHOPT takes around 60 hours to solve a sampled trace covering roughly 10 seconds. Direct comparison on our full traces is impractical: CHOPT’s access-level graph is too large to solve, while ChOMP’s aggregated graph remains tractable. 3.2

Simulator

ChOMP optimizes a placement-and-migration cost model; it does not directly predict application runtime. Our tracedriven simulator (Figure 4) replays arbitrary policies using a common latency, queueing, and bandwidth model without simulating a full CPU. Because replay captures timing effects

MANTA : Machine Learning Augmented Tiering Advisor

EuroSys ’27, April 19-23, 2027, Rabat, Morocco

Simulator

Comparing Tiering Policies to ChOMP. Two behaviors explain heuristic policies’ shortfalls. First, these policies are generally slow to react when a page changes hotness. A page that transitions from cold to hot may require several control intervals before it crosses the promotion threshold, which delays migration until much of the benefit has already passed. When a page becomes cold, delayed demotion leaves it occupying fast-memory capacity that could hold currently useful pages. Figure 1 illustrates this effect. Second, many policies encode heuristics for simple patterns that break down on more complex access sequences. For example, ARMS requires two consecutive increases in its hotness score to trigger a migration. This is intended to prevent one-off sequential scans from triggering migrations after the scan has passed, but it can fail on workloads with repeated sequential phases, where the same conservative rule delays useful promotions. Reactive policies assume that recently measured signals, such as moving averages, are directly informative about future page usefulness. A learned policy can instead model richer relationships between past access patterns and future page importance over the next migration interval. We explore these timing differences further in Section 5.5. Overall, these observations motivate MANTA’s prediction of future usefulness early enough for migration to pay off.

Memory Trace

Initial Placement Policy

MESS

Access Queue

Tiering Policy

Figure 4. Tiering simulator design: ❶ sampled memory trace, ❷ per-page write cap approximating caching, ❸ initialplacement and tiering policies, ❹ MESS latency model, and ❺ shared access queue for backpressure. beyond ChOMP’s aggregated cost model, optimality under ChOMP’s objective does not guarantee minimum simulated runtime, even among interval-based policies. Inputs are a memory trace, tier sizes, latency–bandwidth profiles, an initialization policy, and a migration policy. Before replay, we measure the L3 write hit rate and estimate memory parallelism from trace execution rates under all-fast and all-slow memory configurations. We collect the memory trace (❶) with Intel PEBS, sampling one in 10,007 events. Reads use MEM_LOAD_L3_MISS_RETIRED.LOCAL_DRAM; writes combine MEM_INST_RETIRED.ALL_STORES with L3_HIT.ANY_SNOOP to estimate write-back traffic. Because the trace does not identify which stores hit in cache, we approximate caching by capping each page’s write count per time step according to the measured L3-miss rate (❷). The histogram’s red line marks this cap, and its orange portions show the writes removed. These samples estimate per-page traffic while limiting tracing overhead. The policy interface (❸) separates initial placement from migration decisions during replay. The initialization policy selects the initial contents of fast memory; the tiering policy then chooses promotions and demotions as execution proceeds. This extensible interface includes MANTA, ARMS, TPP, and a policy that replays ChOMP’s schedule. All-fast and allslow references keep every page in the corresponding tier with migration disabled. For each demand access or migration transfer, MESS [18] (❹) returns a latency based on current bandwidth usage. We use MESS’s DDR4 configuration for fast memory, matching our hardware, and measured curves for emulated CXL. A shared access queue (❺) models CPU-side timing and backpressure, with the parallelism estimate determining how many operations may be in flight. Queueing can delay both accesses and migrations; those delays change the traffic seen by subsequent accesses, feeding back into their latency. Replaying the full trace with this feedback yields the simulated runtime. Simulator fidelity. Simulated all-DRAM and all-CXL runtimes differ from hardware measurements by less than 0.1% on all measured workloads (XSBench, PR-Kron, PR-Twitter, BC-Kron, BC-Twitter, NAS MultiGrid, FAISS, and DuckDB). These endpoint comparisons show the fit to measured runtimes and support controlled policy comparisons.

4

Design

MANTA replaces heuristic page-hotness estimates with predictions of future usefulness. Prior systems [24, 35, 37, 48] improve on Linux-style tiered-memory management with heuristics based on access frequency, recency, or combinations of the two. These heuristics differ in detail, but they share the assumption that recent behavior is a reliable guide to future behavior. As shown in Section 3, that assumption breaks down for workloads whose access patterns evolve continuously or shift abruptly. MANTA learns how a page’s access history relates to its future accesses, allowing the policy to anticipate changes in page usefulness. We train a separate model for each application and evaluate one application at a time. During training-data collection and online deployment, PEBS counters are scoped to the target application, so only its sampled memory accesses contribute to the model’s features. Evaluating one application at a time follows prior learned tiering work (Kleio [11]) and the per-application evaluations of ARMS, Memtis, HybridTier, and NOMAD [24, 37, 45, 48]. 4.1

Starting System Design

We build on ARMS [48], a strong baseline whose hotnessbased decisions and migration-control mechanisms let us isolate the benefit of prediction. We replace its two policy components, hotness estimation and migration-candidate selection, with a learned predictor and a rank-based filter.

EuroSys ’27, April 19-23, 2027, Rabat, Morocco

Johannes Freischuetz et al.

Its three mechanism components, access tracking, migration execution, and capacity management, remain unchanged. 4.2 MANTA Model Figure 5 shows the integration. The predictor produces a continuous usefulness score for ARMS’s page ranking. We retain ARMS’s bandwidth-aware throttling, which adjusts migration batch size and concurrency using measured application bandwidth and migration latency [48]. 4.2.1 Prediction Objective. To recognize changing hot sets without overreacting to transient accesses, we predict discounted future page accesses, inspired by discounting in game theory [1]: 𝑉𝑝 (𝑡) =

𝐻 ∑︁

𝛾 𝑖 −1 · 𝑎𝑝 (𝑡 + 𝑖)

(1)

𝑖=1

Here, 𝑎𝑝 (𝑡 + 𝑖) counts accesses to page 𝑝 at step 𝑡 + 𝑖, 𝐻 is the largest future offset available in the trace, and 𝛾 ∈ [0, 1] controls the relative weight of later accesses. The sum begins with step 𝑡 + 1 and excludes accesses in the current step. We count all accesses equally, without weighting by type or latency. Larger values of 𝛾 emphasize persistent access intensity, while smaller values make the target more responsive to immediate changes. We use 𝛾 = 0.99 to give nearer accesses more weight while still counting accesses far into the trace. We leave systematic tuning of this value to future work. This target is the forward-looking counterpart to policies that use moving averages of past accesses [48]. 4.2.2 Features. Table 2 lists the features and their sources. We aggregate Intel PEBS samples of memory-access events, including LLC misses, into per-page histories. Moving averages capture temporal patterns [48], page age identifies potentially hot new allocations [28], read/write ratios distinguish access behavior [35], and neighboring-page statistics capture spatial correlations [12, 13]. We inherit ARMS’s 2- and 20-step EWMA horizons, adding 5- and 100-step horizons for intermediate and longer-term history. The short horizons expose recent changes, while the longer horizons provide context for distinguishing a sustained hot phase from transient activity. Presenting these histories together lets the model learn their relative usefulness for each application instead of fixing their combination in a heuristic. This follows the multiple-time-scale approach of HybridTier [37], with additional precedent for EWMA histories in Memtis and ArtMem [24, 52]. The global_avg_accesses feature is a running average of accesses per step over the page’s observed history, extending the use of accumulated access statistics in prior systems [11, 24, 35]. Spatial features use a base neighborhood of eight 2 MB hugepages (16 MB). group_above and group_below each aggregate three consecutive neighborhoods immediately above

or below the target neighborhood, covering 48 MB per feature. Preliminary experiments found three neighborhoods sufficient for spatial context. These sizes are fixed across workloads. 4.2.3 Data Collection. We collect 10 all-DRAM traces per application with tiering disabled, avoiding migrationinduced changes to training accesses. During collection and deployment, application-scoped PEBS counters exclude operating-system, policy, and other applications’ accesses from model features. We compute each page’s target at each step using Equation 1. For each workload, we fit candidate models on eight traces and evaluate them on two held-out traces during SMAC hyperparameter search [22]. We then train the deployed model on all 10 traces. 4.2.4 Virtual Time Steps. ARMS’s control loop uses fixed wall-clock intervals, typically 250 ms. Such windows couple features to execution speed: tiering-induced slowdowns change the number of accesses per window, potentially shifting features outside their training distribution. The same application phase can therefore produce different feature magnitudes during all-DRAM training and tiered execution, even when its underlying access pattern is unchanged. We instead advance virtual time after a fixed number of the application’s PEBS samples. This measures access history in units of application progress and reduces the feedback from earlier placement decisions into the feature representation. To balance temporal resolution against bookkeeping and inference costs, we measure samples per 250 ms during allDRAM execution and round to the nearest 10𝑘/2 for integer 𝑘. This yields 10,000 samples per step for most workloads, 3,162 for FAISS [15], and 100,000 for DuckDB. Section 5.7.2 evaluates this choice. 4.2.5 Model Architecture. Scoring tens of thousands of pages multiple times per second constrains the models that are practical for online tiering. We use a LightGBM randomforest regressor [23] for low-latency inference on structured features. Using lleaves [8], we compile the trained model to standalone native code, avoiding the full LightGBM runtime in the online path. Compilation reduces inference time by an order of magnitude to under 20 ms for more than 10,000 pages, enabling predictions every control interval. 4.2.6 Parameters and Tuning. SMAC [22] searches a predefined regressor-hyperparameter space using a small data subset. It tunes only model hyperparameters, which affect accuracy, size, and inference cost. Features, EWMA horizons, and neighborhood sizes are fixed across workloads. 4.2.7 Migration Candidate Filter. At deployment, we turn the model’s predictions into migration decisions in two steps: average each page’s predictions over the last 10 control intervals to stabilize its score, then filter the resulting page ranking to select promotions and demotions. Smoothing

MANTA : Machine Learning Augmented Tiering Advisor

EuroSys ’27, April 19-23, 2027, Rabat, Morocco

MANTA Feature Generation

ARMS Mechanisms Learned Scoring

PEBS Samples

Migration Mechanisms

Learned Scoring Higher Scores

Lower Scores

…

Cost Benefit Analysis

Parallel Migrations

Migration Rate Limiter

Figure 5. MANTA integration: blue components are added or modified, orange provided by the kernel, and yellow inherited from ARMS. Feature

Description

Prior source(s)

ewma_2, ewma_5, ewma_20, ewma_100 global_avg_accesses

Exponentially weighted moving averages of page accesses using several target window sizes Running average of the page’s accesses per step over its observed history The age of the page in steps

ARMS [48]; HybridTier [37]; Memtis [24]; ArtMem [52] HeMem [35]; Memtis [24]; HybridTier [37]; Kleio [11] HeMem [35]; Memtis [24]; TPP [28]; ARMS [48]; HybridTier [37]; NOMAD [45] HeMem [35]; Vulcan [39] Cronus [13]; Coeus [12]

age r_ratio_20, r_ratio_100 group_above, group_below nearby_pages nearby_ewma5_var

Long-term read/write ratios for the page Average access count over three consecutive eight-page neighborhoods immediately above or below the target neighborhood (48 MB per feature) Average access count in the eight-page (16 MB) neighborhood containing the hugepage Variance of the access-count EWMA within the eight-page (16 MB) neighborhood containing the hugepage

Cronus [13]; Coeus [12] Cronus [13]; Coeus [12]; ARMS [48]

Table 2. Runtime features used by the current predictive model.

Hot Set

Cold Set

Migration Filter Figure 6. MANTA’s rank filter replaces ARMS’s hotnessdependent filters. reduces noise in the predicted scores, but can delay reactions to abrupt changes in access patterns. Additionally, a high predicted score identifies a useful page, but does not by itself justify moving it immediately because migration consumes bandwidth and can interfere with application accesses. ARMS’s cost-benefit mechanism couples migration decisions to the momentum of its hand-engineered hotness scores [48]. It estimates migration benefit from reactive scores and hot age, then compares that benefit with observed migration costs. These inputs do not map directly onto MANTA’s predictions of future usefulness. We therefore use a simpler rank-based filter that operates directly on the ordered hot and cold sets shown in Figure 6. The hot set contains the highest-ranked pages up to the fastmemory capacity, and the cold set contains the remaining pages below that capacity boundary. A page in slow memory is a promotion candidate only if it lies in the top half of the hot set. A page in fast memory is a demotion candidate only if it lies in the bottom half of the cold set. The hatched region in the figure covers the excluded halves adjacent to the capacity boundary. These pages stay in place that interval.

We do this because the model predictions can be noisy near the migration threshold, where small score fluctuations can otherwise cause unnecessary page movement. Together, prediction smoothing and rank filtering reduce churn and keep the system from spending migration bandwidth on pages whose predicted ordering is unstable from one interval to the next. Using ranks avoids calibrating a migration-cost multiplier for each workload; the rank threshold and predictionsmoothing window remain fixed across the workloads we evaluate. Section 5.7.1 compares this rank threshold with an ARMS-like cost-benefit check applied to our learned scores, using a fixed migration-cost scaler for each configuration. 4.2.8 Model Validity and Retraining. We evaluate applications individually, without co-running workloads. Under co-location, each application would need its own model and features while sharing memory and migration bandwidth. Application-scoped counters separate feature streams, but do not isolate access timing or performance from other tenants’ contention. ARMS throttling limits migration pressure without providing cross-tenant bandwidth allocation, fairness, or performance isolation; evaluating these scenarios remains future work. Model reuse depends on whether new access behavior remains represented by the training traces. A new dataset or input size does not necessarily require retraining; we evaluate transfer across datasets, sizes, and execution lengths in Section 5.4. Changes to code, control flow, input type, dataset

EuroSys ’27, April 19-23, 2027, Rabat, Morocco

size or skew, thread count, or algorithm parameters can nevertheless shift access behavior. After such changes, the operator must validate predictions and runtime features on representative traces. Retraining is required when features fall outside the training distribution, or prediction quality or application performance degrades. Validation must therefore assess decision quality as well as feature distributions: a model can lose its usefulness even when no individual feature gives an obvious drift signal. We use an operator-managed lifecycle: collect new PEBS traces, rebuild the model off-host, and replace it. Section 5 quantifies rebuilding cost. Monitoring input distributions and decision quality, as proposed by Guardrails for the OS [36], could trigger heuristic fallback or retraining. Automatic drift detection and online updates remain future work.

5

Evaluation

In this section, we compare MANTA against existing tiering policies. We ask four questions: (1) How does MANTA perform across workloads, kernels, and memory technologies? (2) How well does a model transfer to new inputs and longer executions? (3) How much of the gap to ChOMP does it recover? (4) What are its prediction accuracy, overhead, and sensitivity to individual design choices? We use two hardware configurations. The first is a c220g5 CloudLab [17] machine that emulates CXL using a downclocked remote NUMA node, similar to prior work [27, 42, 48]. The second is a self-hosted Optane-based system. Workloads. We evaluate workloads sensitive to memory tiering, running one application at a time without competing background workloads or multi-tenancy. For graph analytics workloads, we use Betweenness Centrality (BC) [4] and PageRank (PR) [31] on the Kron and Twitter graphs (BC-Kron, BC-Twitter, PR-Kron, and PR-Twitter). For scientific computing, we use XSBench [40], an application for Monte Carlo neutron transport, and NAS MultiGrid (Class D) [3], an application that benchmarks multigrid solvers. For vector databases, we use FAISS [15] on OpenAI text embeddings [30]. Finally, for databases, we use DuckDB [33] running the TPC-H SF100 [32] workload. We use all eight workloads on emulated CXL; Optane experiments omit DuckDB and NAS MultiGrid because both perform extremely poorly when pages are placed in Optane (Section 5.3). The policy ablations use BC-Twitter and PR-Twitter to contrast workloads with larger and smaller gains from prediction (Section 5.7.2). The main workloads have memory footprints of 13–27 GB; the larger-input experiment is described separately in Section 5.4.3. The 4–10 GB fast tier is smaller than each workload’s full footprint; increasing its capacity allows more frequently accessed pages to remain in fast memory. MANTA uses 2 MB pages, and the capacities on the x-axes denote fast-tier memory, not total workload size. We

Johannes Freischuetz et al.

vary fast-memory capacity because it affects policy performance [24, 37]. Each tiering-policy workload, memory capacity, and kernel combination is repeated three times. Perworkload error bars show the minimum and maximum perrun speedups. System Setup. Across evaluations, we use the same workloads and, where possible, comparable kernel versions so that differences reflect tiering policy rather than unrelated system changes. For the emulated-CXL experiments, we run on a CloudLab c220g5 node [17] with two NUMA regions, each containing a Xeon Silver 4114 CPU and 192 GB of DRAM. One NUMA region serves as fast memory and the other as slow memory. To make the remote NUMA region more representative of CXL, we downclock its uncore frequency to 700 MHz, increasing access latency using the same methodology as prior work [48]. The baseline implementations use different patched kernels, as detailed in Section 5.1. Our Linux 6.2 results use HybridTier’s patched 6.2.0-hybridtier+ kernel for MANTA, ARMS, and HybridTier. We then repeat the ARMS-versus-MANTA comparison on Linux 6.18.1 to evaluate performance on a newer kernel. Both kernel versions use the same Spectre mitigations. The all-DRAM and all-CXL references include both kernel series. Finally, we repeat the experiments again on our Optane system with the Linux 6.18.1 kernel. Our Optane system uses an Intel(R) Xeon(R) Gold 6226R CPU, with six channels of SK Hynix 32GB PC4-25600 DDR4-3200MHz as fast memory, and Intel Optane Persistent Memory 100 Series devices as slow memory in the same NUMA region, providing 135 GB of remote memory. Model-Building Cost. Figure 14 reports measured model build times of 455–883 s across the eight workloads, rounded to whole seconds. We sum hyperparameter search, fulldataset construction, finalist evaluation, final test evaluation and model saving, and model compilation from each model’s timing log. This sum excludes trace collection, input discovery, dependency loading, and streaming/reservoir sampling. This offline cost is paid at model creation and retraining (Section 4.2.8), not on each application run. 5.1

Comparison with Baselines on Emulated CXL

We first compare MANTA against all selected baselines using emulated CXL. We use ARMS, TPP [28], HybridTier [37], NOMAD [45], and Memtis [24] as our baselines. We omit a separate TPP+Colloid experiment and use TPP as the baseline for this single-application evaluation. This is because TPP is roughly equivalent to TPP+Colloid in the single-application regime where the default tier remains lower-latency under load: the Colloid paper’s default GUPS experiment reports matching performance at 0× injected memory-interconnect contention [42]. TPP, HybridTier, NOMAD, and Memtis are kernel implementations. TPP uses Linux 5.15.0+ with TPP patches, and HybridTier uses Linux 6.2.0-hybridtier+. NOMAD uses Linux 5.13.0-rc6+ with NOMAD patches and

MANTA : Machine Learning Augmented Tiering Advisor

EuroSys ’27, April 19-23, 2027, Rabat, Morocco

(e) XSBench

4

6

8

10

Memory Footprint (GB)

4

6

8

Memory Footprint (GB)

(f) FAISS

10

DRAM

1.78× 1.68× 1.46× 1.71× 1.86× 1.92×

1.93× 1.91× 1.47× 1.53× 2.00× 2.05×

2.00×

2.0 1.5 1.0 0.5

4

6

8

10

1.42×

2.5

1.01× 0.89× 0.91× 0.91× 0.86× 1.12×

2.52×

0.5

DRAM

3.0

Speedup vs. all CXL

1.0

10

(d) PR-Twitter

1.43× 1.37× 1.58× 1.44× 1.14× 1.09×

Speedup vs. all CXL

1.65×

DRAM

1.5

8

Memory Footprint (GB)

2.5 2.0

1.86× 1.77× 1.35× 1.63× 1.94× 1.93×

1.50×

Speedup vs. all CXL

1.44× 1.36× 1.30× 0.53× 1.26× 1.52×

1.09×

4

(c) BC-Twitter

1.31× 1.13× 1.17× 1.21× 1.29× 1.28×

1.22× 1.13× 1.08× 1.12× 1.18× 1.17×

1.08× 1.04× 1.05× 0.93× 0.85× 0.92×

2.10×

DRAM

0.5

DRAM

6

1.0

1.15× 1.08× 0.90× 0.79× 0.79× 1.10×

10

0.5

10

3.0

2.0

1.0

8

1.5

Memory Footprint (GB)

2.5

1.5

6

2.0

1.11× 1.05× 0.84× 0.84× 0.73× 1.10×

8

Memory Footprint (GB)

Speedup vs. all CXL

1.87× 1.50× 1.57× 1.43× 1.83× 2.02×

1.86× 1.52× 1.54× 1.56× 1.86× 2.00×

1.89× 1.50× 1.49× 1.64× 1.72× 2.01×

6

4

2.5

1.05× 0.98× 0.86× 0.79× 0.77× 1.11×

4

1.42× 1.22× 1.17× 1.03× 0.71× 1.11×

1.98×

Speedup vs. all CXL

1.88× 1.81× 1.40× 1.97× 1.93× 1.81×

1.89× 1.80× 1.48× 1.92× 2.03× 1.85×

DRAM

(b) PR-Kron

1.0 0.5

10

3.0

1.86× 1.53× 1.50× 1.72× 1.79× 1.45×

Speedup vs. all CXL

1.5

1.88× 1.80× 1.45× 1.75× 1.94× 1.64×

1.67×

(a) BC-Kron 3.0

2.0

8

0.5

Memory Footprint (GB)

Memory Footprint (GB)

2.5

6

1.0

1.44× 1.36× 1.09× 0.84× 1.22× 1.49×

4

1.5

1.34× 1.23× 1.41× 1.33× 1.10× 1.09×

0.5

DRAM

1.87× 1.70× 1.63× 1.62× 1.25× 1.07×

1.0

2.0

1.43× 1.36× 1.01× 0.69× 1.23× 1.17×

10

Speedup vs. all CXL

1.52× 1.45× 1.20× 0.50× 1.14× 1.41×

8

1.5

3.0

2.5

1.20× 1.20× 1.24× 1.17× 0.90× 1.07×

6

2.0

Nomad

1.11× 1.06× 1.09× 1.05× 0.89× 1.01×

4

2.5

HybridTier DRAM

3.0

1.14× 1.11× 0.96× 1.00× 1.11× 1.07×

0.5

1.49× 1.45× 1.11× 0.73× 1.08× 1.38×

1.0

1.52× 1.43× 1.00× 1.02× 1.08× 0.96×

1.5

1.44× 1.17× 1.10× 1.00× 0.83× 1.04×

Speedup vs. all CXL

2.5 2.0

ARMS MEMTIS

1.76× 1.67× 1.51× 1.65× 1.51×

MANTA TPP

3.0

3.0

DRAM

Memory Footprint (GB)

(g) NAS MultiGrid

(h) DuckDB

Figure 7. Speedup over all-CXL execution on emulated CXL. Higher is better. MANTA, ARMS, and HybridTier run on Linux 6.2-hybridtier. Other baselines use their patched kernels (Section 5.1). the async_promote module. Memtis uses Linux 5.15.19 with HTMM patches. ARMS and MANTA share HybridTier’s kernel. Figure 7 shows our results. MANTA has the highest geometric-mean speedup of all evaluated systems at every capacity. The strongest aggregate baseline is ARMS at 4 and 6 GB and Memtis at 8 and 10 GB; MANTA outperforms these baselines by approximately 1.12×, 1.07×, 1.03×, and 1.03×, respectively. Against Memtis alone, the corresponding speedups are approximately 1.28×, 1.11×, 1.03×, and 1.03×. Against ARMS, the geometric-mean speedups at 4, 6, 8, and 10 GB are approximately 1.12×, 1.07×, 1.08×, and 1.08×, respectively. Individual workloads can still favor another system, as the panels show. For BC, MANTA achieves 1.03–1.24× speedup over ARMS on BC-Kron and 1.05–1.16× on BC-Twitter. It outperforms every baseline on BC-Kron, including 1.08–1.59× gains over Memtis. On BC-Twitter, MANTA outperforms Memtis by 1.28× and 1.22× at 4 and 6 GB, respectively, while Memtis is 1.03× and 1.05× faster at 8 and 10 GB. On XSBench, MANTA achieves 1.22–1.25× speedup over ARMS across capacities. It also outperforms Memtis by 1.28× at 4 GB, but Memtis leads by 1.07–1.08× at 6–10 GB. MANTA and TPP are within 1% at 8 GB; MANTA leads TPP at the other capacities. On FAISS, MANTA outperforms every plotted baseline, with gains of 1.02–1.17× over Memtis. DuckDB has a different ordering: Memtis is 1.11× and 1.05× faster than MANTA at 4 and 6 GB, respectively; the two are within 1% at 8 GB, and MANTA leads by 1.04× at 10 GB. MANTA nevertheless outperforms ARMS on DuckDB at every capacity, by 1.06–1.13×. For PR, MANTA achieves 1.04–1.10× speedup over ARMS on PR-Kron and 1.01–1.06× on PR-Twitter. It outperforms Memtis by 1.02–1.75× on PR-Kron, although TPP or NOMAD can lead at larger capacities. On PR-Twitter, MANTA leads Memtis by 1.61× at 4 GB, while Memtis is 1.04–1.08× faster at 6–10 GB. For NAS MultiGrid, MANTA outperforms Memtis

by 1.10–1.31× and remains within 1% of ARMS at 6 GB, but HybridTier is 1.04–1.10× faster than MANTA at 6–10 GB. Kernel behavior accounts for much of this performance difference between MANTA and other baseline systems. There is one exception to this in DuckDB, which benefits from initial placement policies that ARMS and MANTA do not have. Further differences are explored in Section 5.5. MANTA and ARMS share HybridTier’s kswapd changes in 6.2, while Memtis, TPP, and NOMAD use their own patched kernels. Additionally, these systems implement their own memory-management mechanisms inside the kernel, which enables initial placement policies which we cannot support, as well as base page migrations. Comparing MANTA with ARMS on the same kernel holds these kernel mechanisms constant while assessing MANTA’s policy changes. Figure 13 complements the measured system comparisons with a simulated ChOMP reference. We next repeat the MANTA-versus-ARMS comparison on Linux 6.18 to test whether MANTA’s gains persist on a newer kernel. 5.2

Comparison on a New Kernel

We next rerun MANTA and ARMS on Linux 6.18 to examine how the newer kernel affects their performance and whether MANTA’s gains persist, as shown in Figure 8. We reuse the Linux 6.2 models unchanged, without retraining or retuning. We attribute the main performance difference between these kernels to additional kswapd activity from HybridTier’s 6.2 patches in our setup, as well as improvements in memory management and CPU scheduling in Linux 6.18. Across the eight workloads, MANTA achieves approximately 1.08×, 1.03×, 1.06×, and 1.07× geometric-mean speedup over ARMS on Linux 6.18 at 4, 6, 8, and 10 GB, respectively. Because the other baseline implementations do not support this kernel, the direct comparison is between MANTA and ARMS; we also include their Linux 6.2 performance values and the bestperforming baseline not already included in the figure for

EuroSys ’27, April 19-23, 2027, Rabat, Morocco

Johannes Freischuetz et al.

10

(e) XSBench

4

8

Memory Footprint (GB)

4

6

8

10

Memory Footprint (GB)

(f) FAISS

2.02× 1.67× 1.73× 1.57× 1.79×

2.05× 1.80× 1.87× 1.78× 1.92×

2.11×

DRAM

(g) NAS MultiGrid

DRAM

3.0 2.5 2.0 1.5 1.0 0.5

6

8

10

4

1.41×

2.51× 1.52× 1.43× 1.36× 1.37× 1.57×

1.65×

DRAM

Speedup vs. all CXL

1.29× 1.31× 1.06× 1.13× 1.29×

10

1.0 0.5

10

Memory Footprint (GB)

(d) PR-Twitter

2.5

1.5

8

4

(c) BC-Twitter

2.0

1.86× 1.74× 1.70× 1.65× 1.81×

1.83× 1.64× 1.72× 1.56× 1.54×

1.64×

Speedup vs. all CXL

1.51× 1.13× 1.54× 1.07× 1.19×

1.53× 1.11× 1.30× 0.95× 0.91×

2.12×

Speedup vs. all CXL

1.98× 1.72× 1.99× 1.64× 1.84×

1.98× 1.71× 2.01× 1.65× 1.79×

1.99× 1.71× 2.02× 1.64× 1.76×

6

1.21× 1.22× 1.12× 1.12× 1.17×

1.05× 1.08× 1.06× 1.04× 1.04×

2.10×

DRAM

0.5

DRAM

6

1.0

1.17× 1.07× 1.06× 1.01× 1.03×

8

Memory Footprint (GB)

10

3.0

2.0

0.5

8

1.5

Memory Footprint (GB)

2.5

1.0

6

2.0

1.13× 1.03× 1.01× 0.98× 1.02×

6

4

2.5

1.06× 0.98× 0.96× 0.91× 1.03×

4

Speedup vs. all CXL

1.87× 1.85× 1.73× 1.48× 2.00×

1.89× 1.84× 1.77× 1.51× 1.97×

1.87× 1.86× 1.72× 1.49× 1.99×

1.88× 1.84× 1.62× 1.51× 1.77×

Speedup vs. all CXL

DRAM

(b) PR-Kron

1.0 0.5

10

0.5

3.0

1.5

DRAM

Speedup vs. all CXL

(a) BC-Kron

1.5

8

1.0

Memory Footprint (GB)

3.0

2.0

6

1.5

1.53× 1.13× 1.53× 1.07× 1.17×

4

2.0

1.36× 1.34× 1.25× 1.23× 1.41×

DRAM

1.98× 1.70× 1.88× 1.55× 1.48×

1.0

2.5 1.48× 1.12× 1.52× 1.07× 0.96×

10

1.80×

1.62× 1.29× 1.64× 1.23× 1.20×

1.62× 1.26× 1.63× 1.23× 1.17×

8

1.5

0.5

Best Baseline 3.0

1.22× 1.20× 1.19× 1.19× 1.24×

6

2.0

ARMS 6.2

1.11× 1.11× 1.11× 1.06× 1.08×

4

2.5

Memory Footprint (GB)

2.5

ARMS 6.18 3.0

1.10× 1.14× 1.10× 1.10× 1.11×

0.5

Speedup vs. all CXL

1.0

1.60× 1.29× 1.62× 1.21× 0.92×

1.5

1.51× 1.22× 1.38× 0.99× 0.93×

Speedup vs. all CXL

2.5 2.0

MANTA 6.2

3.0

1.01× 0.94× 0.91× 0.83× 1.05×

MANTA 6.18 3.0

DRAM

Memory Footprint (GB)

(h) DuckDB

Figure 8. Speedup over all-CXL execution on Linux 6.18. Linux 6.2-hybridtier results, the best baseline, and all-DRAM references are included. Higher is better. each workload and capacity. The “Best Baseline” bars select the lowest mean runtime among HybridTier, NOMAD, TPP, and Memtis separately for each workload/capacity combination, excluding ARMS and MANTA. MANTA retains its aggregate advantage on the newer kernel, with sustained gains across capacities on several workloads. On DuckDB, it delivers approximately 1.11× speedup over ARMS at every capacity. On PR-Twitter, its 1.06–1.17× gains exceed the 1.01–1.06× range on Linux 6.2. XSBench retains a 1.07–1.16× advantage, although smaller than its 1.22–1.25× gains on Linux 6.2. The capacity trends differ by workload. For FAISS, MANTA’s speedup grows to 1.08× and 1.21× at 8 and 10 GB, respectively; at 4–6 GB, the systems are within 1.3%. Similarly, NAS MultiGrid improves from a near-tie at 4 GB to 1.03×, 1.09×, and 1.12× at 6, 8, and 10 GB, with no regression against ARMS. For BC and PR-Kron, the gains are concentrated at the smallest fast-tier capacity: at 4 GB, MANTA achieves 1.09× on BC-Kron, 1.18× on BC-Twitter, and 1.06× on PR-Kron. At 6–10 GB, these three workloads remain close to ARMS, which leads by at most 3.1%. 5.3

Comparison on Optane

We use Optane to represent slow memory with different latency and bandwidth characteristics from emulated CXL. The Optane experiment uses a smaller workload subset: the four graph workloads, XSBench, and FAISS. We remove DuckDB and NAS MultiGrid as they perform poorly when any amount of memory is placed in Optane. We compare only against ARMS because the Optane machine does not support the kernel changes required by the other baselines. Figure 9 reports speedup relative to all-Optane execution, with allDRAM execution as a reference; higher values indicate better performance. Across the six workloads, MANTA achieves approximately 1.69×, 1.13×, 1.14×, and 1.09× geometric-mean

speedup over ARMS at 4, 6, 8, and 10 GB, respectively. The largest plotted speedup ratio is 5.63× on PR-Twitter at 4 GB; PR-Kron reaches 2.00× at the same capacity. The clearest gains occur for BC, XSBench, and PR under memory pressure. As fast-memory capacity grows, MANTA’s advantage on PR narrows, with regressions of up to about 4% relative to ARMS at some larger capacities. Across the four capacities, FAISS’s mean runtimes differ by only 0.2–1.7%, so these measurements show little benefit from changing the policy on that workload. 5.4

Generalization to New Settings

5.4.1 Longer Workload Runs. Figure 10 compares MANTA and ARMS on longer executions of BC-Twitter and PR-Twitter on Linux 6.18 across four memory capacities. We extend both workloads to 100 iterations, 10× the training-run iteration count, while retaining the fixed models used in Figure 7. We measure new all-DRAM and all-CXL references for these longer executions. For the comparisons below, we divide ARMS’s mean runtime by MANTA’s mean runtime over three successful runs per configuration; ratios above one favor MANTA. At 4, 6, 8, and 10 GB, respectively, these ratios are approximately 1.086×, 1.069×, 1.004×, and 0.999× for BC-Twitter. Runtime is 7.9%, 6.5%, and 0.4% lower at 4, 6, and 8 GB, respectively, and 0.1% higher at 10 GB. Thus, BC-Twitter retains an advantage at the smaller capacities, although its 4 GB advantage narrows from approximately 1.18× in the shorter Linux 6.18 run. For PR-Twitter, the longer-run ratios are approximately 0.984×, 0.987×, 0.972×, and 0.997×: runtime increases by 1.7%, 1.3%, 2.9%, and 0.3%, respectively. Its approximately 1.06–1.17× advantage in the shorter Linux 6.18 runs therefore does not persist. The workloads differ in how their access patterns evolve: BC remains relatively stable throughout the trace, whereas

MANTA : Machine Learning Augmented Tiering Advisor

EuroSys ’27, April 19-23, 2027, Rabat, Morocco

(a) BC-Kron

4

(b) PR-Kron

6

4

6

8

Fast Memory (GB)

(c) BC-Twitter

(d) PR-Twitter

4

6

8

15

4.89×

10

10 DRAM

Fast Memory (GB)

(e) XSBench

4

6

10 DRAM

1.38×

8

1.39×

1.38×

1.38×

1.29×

5 1.28×

6.91×

Speedup vs. Optane

1.29×

5

7.38×

7.42× 4.19×

7.36×

10

6.76×

15

1.07×

11.46×

10 DRAM

Fast Memory (GB)

Speedup vs. Optane

5

11.23×

11.25×

9.02×

10

1.60×

10 DRAM

4.48×

8

Speedup vs. Optane

5.51×

4.64×

4.84× 1.47×

10 DRAM

Fast Memory (GB)

Fast Memory (GB)

DRAM

15

1.40×

8

5

ARMS

1.37×

6

10 4.72×

4

10 DRAM

15

0.99×

Speedup vs. Optane

5

2.14×

10

1.07×

Speedup vs. Optane

3.21×

8

2.12×

1.97×

3.08×

6

15

4.29×

4

2.25×

1.15×

5

2.73×

10

1.01×

Speedup vs. Optane

MANTA 15

Fast Memory (GB)

(f) FAISS

Figure 9. Speedup over all-Optane execution, with an all-DRAM reference. Higher is better. MANTA

ARMS

6

8

10 DRAM

(a) BC-Twitter

2.29×

2.23×

8

10 DRAM

2.14×

1.91×

1.88×

1.84×

2.22×

4

Memory Footprint (GB)

2.0

2.20×

0.5

2.5

1.87×

2.08×

1.88×

1.88×

1.86×

1.87×

1.56×

1.67×

1.0

Speedup vs. all CXL

1.5

1.37×

2.5 2.0

DRAM

3.0

1.49×

Speedup vs. all CXL

3.0

1.5 1.0 0.5

4

6

Memory Footprint (GB)

(b) PR-Twitter

Figure 10. Longer runs on Linux 6.18. Speedup is over allCXL execution, with an all-DRAM reference. Higher is better. PR’s patterns drift as execution progresses [41]. We interpret BC-Twitter’s gains at smaller capacities and near-ties at larger capacities as consistent with the model being able to generalize from the training run to the longer execution. For PR-Twitter, a shift in the access distribution during later phases can reduce the representativeness of the training data and explain the loss of the original run’s advantage. These results illustrate the model-validity limits in Section 4.2.8: extending execution can preserve useful predictions, but later phases outside the training distribution require validation and potentially retraining. The model remains fixed throughout this experiment; it does not adapt through online retraining. Section 5.6 reports per-step prediction-quality percentiles; these do not measure the distribution of interval-level runtime slowdowns. 5.4.2 Cross-Dataset Transfer. For both BC and PR, we deploy the model trained on Twitter on the Kron graph, and vice versa. Figure 11 compares these transferred models with ARMS and the dataset-specific models from Figure 7 on Linux 6.2, using speedup over all-CXL execution. The transferred models generally match or outperform ARMS while retaining the advantage of the dataset-specific models. The occasional regressions, including PR-Twitter at the largest capacity, show that the benefit is not uniform across configurations. These results support reuse on new datasets of the trained applications, subject to validation when access behavior changes (Section 4.2.8). 5.4.3 Dataset-Scale Transfer. We scale the Kron graph from 20 to 80 GB while retaining the same degree parameter, and reuse the earlier BC-Kron and PR-Kron models for their respective workloads. Figure 12 compares these models with

ARMS on Linux 6.18. The models, features, virtual-step size, and 2 MB page size remain unchanged, with no retraining or retuning. The 80 GB input size denotes the graph data. The measured resident footprints are close to 80 GB, with only marginal additional overhead. For BC, transfer achieves speedups over ARMS of 1.11× and 1.09× at 4 GB and 6 GB, respectively, with marginal speedups at higher capacities. For PR, the largest benefit occurs at 4 GB with a 1.21× speedup, where there is the most contention for fast-tier memory. The policies converge to be roughly equivalent at larger fast-tier capacities. Transfer broadly preserves the benefits seen on the smaller graph, particularly under memory pressure. The larger working set makes PR more difficult for ARMS at the smallest capacity; with more fast memory, the policies converge. These results support reuse within the same graph family, even as the graphs grow in capacity. Input growth alone need not trigger retraining; degraded predictions or performance should prompt validation and, where necessary, retraining (Section 4.2.8).

5.5

Simulator Evaluation

We use the simulator to measure how much of the runtime gap between ARMS and the interval-constrained ChOMP reference is closed by MANTA. Figure 13 compares measured runtimes for MANTA, ARMS, and HybridTier with simulated ChOMP and all-DRAM references across eight workloads and 2-8 GB of DRAM. All bars are normalized to the simulated all-CXL runtime for the corresponding workload. Section 3.2 describes the calibration and reference construction. MANTA recovers much of the available headroom by preventing unnecessary page churn and making useful placements sooner. Its predictions allow it to promote pages without waiting for their reactive hotness scores to “warm up,” while retaining useful pages avoids repeated eviction and promotion. On BC-Twitter at 2 GB, MANTA saves 18.0 s of the 21.8 s gap to ChOMP, recovering 82% and delivering a 1.18× speedup over ARMS. On PR-Twitter at 6 and 8 GB, it saves 47.7 and 27.7 s out of gaps of 60.1 and 35.4 s, recovering 79% and 78%, respectively. At 8 GB, MANTA finishes only 7.8 s, or 2.9%, slower than the ChOMP reference. These results show that predictive placement can remove most of the loss incurred by waiting for reactive scores to catch up.

EuroSys ’27, April 19-23, 2027, Rabat, Morocco

Johannes Freischuetz et al.

8

4

6

8

Memory Footprint (GB)

(a) BC-Kron

(b) PR-Kron

4

6

8

10 DRAM

Memory Footprint (GB)

(c) BC-Twitter

2.0

4

6

8

2.00×

2.5

1.93× 1.87× 1.91×

1.50×

1.44× 1.43× 1.36×

1.44× 1.44× 1.36×

1.43× 1.42× 1.36×

1.0 0.5

10 DRAM

Memory Footprint (GB)

1.5

Speedup vs. all CXL

1.0

2.0

1.42× 1.42× 1.22×

1.98×

1.89× 1.90× 1.80×

1.88× 1.89× 1.81×

1.5

0.5

10 DRAM

1.88× 1.87× 1.80×

2.0

3.0

2.5

1.78× 1.88× 1.68×

6

DRAM

1.86× 1.86× 1.77×

4

2.5

Speedup vs. all CXL

1.0 0.5

ARMS 3.0

1.87× 1.85× 1.70×

Speedup vs. all CXL

1.67×

1.52× 1.55× 1.45×

1.49× 1.51× 1.45×

1.52× 1.51× 1.43×

1.5

1.44× 1.41× 1.17×

Speedup vs. all CXL

2.5 2.0

MANTA transfer

3.0

1.76× 1.81× 1.67×

MANTA 3.0

1.5 1.0 0.5

10 DRAM

Memory Footprint (GB)

(d) PR-Twitter

Figure 11. Cross-dataset transfer on Linux 6.2. Panels name the evaluation dataset. Speedup is over all-CXL execution, with an all-DRAM reference. Higher is better. MANTA transfer

ARMS

4

6

8

10 DRAM

Memory Footprint (GB)

(a) BC-Kron-80GB

1.5

1.99×

1.95×

8

10 DRAM

1.90×

1.88×

1.88×

1.86×

1.54×

2.0

1.90×

0.5

2.5

1.90×

1.0

Speedup vs. all CXL

1.59×

1.39×

1.35×

1.34×

1.25×

1.15×

1.18×

2.0

1.37×

2.5

1.5

DRAM

3.0

1.06×

Speedup vs. all CXL

3.0

1.0 0.5

4

6

Memory Footprint (GB)

(b) PR-Kron-80GB

Figure 12. Model transfer to an 80 GB Kron graph on Linux 6.18. Speedup is over all-CXL execution. Higher is better. Capacity determines how much additional improvement is possible. For BC-Kron, PR-Kron, and BC-Twitter at 4–8 GB, ARMS already captures most of the benefit of fast memory, leaving comparatively little headroom for MANTA to recover. The two policies’ runtimes differ by at most 2% on the Kron workloads and 3.4% on BC-Twitter, including small regressions for MANTA. For example, at 8 GB on BC-Twitter, ARMS and MANTA finish in 97.3 and 99.0 s, compared with 91.7 s for ChOMP. Here, replacing the ranking policy has limited scope to improve performance. On NAS MultiGrid, however, MANTA’s advantage grows with capacity: it saves just 0.3 s at 2 GB, but 44.7 s of a 77.2 s gap at 8 GB, recovering 58%. This pattern is consistent with better page selection becoming more useful as enough fast memory becomes available to retain the selected pages. FAISS illustrates both the benefit of reducing churn and the remaining cost of migration delay. Churn makes ARMS’s placements ineffective, while MANTA’s predictions improve which pages remain in fast memory. At 8 GB, MANTA saves 96.0 s of the 173.3 s gap, recovering 55% and achieving a 1.22× speedup over ARMS. Nevertheless, MANTA still trails ChOMP by 77.3 s because identifying the right pages does not place them in DRAM immediately. At 2–4 GB, the two policies remain within 1.3% of each other despite remaining headroom, so the benefit is concentrated at larger capacities. DuckDB exposes a different limitation: frequent deallocations and reallocations repeatedly discard useful placements. MANTA allocates new pages in the far tier and must subsequently identify and promote them, so repeated allocation forces it to pay this delay again. It still outperforms ARMS by about 1.11× across capacities, recovering 39–55% of the gap,

but much of the allocation-related loss remains. At 2 GB, MANTA saves 48.0 s over ARMS yet remains 39.7 s above ChOMP. Its 443.3 s runtime is just faster than the 445.9 s all-CXL reference; ARMS and HybridTier remain slower than all-CXL execution. Thus, this case calls for better initial placement as well as better hotness prediction. XSBench presents the same placement challenge primarily once, during initial allocation: performance depends on how quickly the useful pages reach the right tier. MANTA avoids waiting for hotness scores to build up and saves 26.3 s of the 44.3 s ARMS-to-ChOMP gap at 2 GB, recovering 59%. Across capacities, its remaining gap stays near 16–18 s, consistent with a placement delay that extra DRAM alone does not eliminate. MANTA also outperforms HybridTier at every capacity on XSBench, DuckDB, and all four graph workloads, although HybridTier retains a small advantage on NAS MultiGrid at 4–8 GB. 5.6

Model Characterization

Figure 14 summarizes prediction quality, per-page and perstep processing time, and model build time across eight workloads. After building each model, we collect separate online traces specifically for this evaluation; they are never used for training or tuning. Model building takes roughly 8–15 minutes for the stages in Section 5. Hyperparameter optimization (HPO) takes about six minutes, with final model building and evaluation accounting for most of the remaining time. Compilation adds less than 1% of the overall time. Feature generation and inference measure the per-page costs of constructing model inputs and computing predictions, respectively. Total reports processing time per timestep, including feature generation and inference; the timing columns report means and, for inference and total, P95 values. 𝑅 2 measures prediction fit to discounted future reward with discount 0.99, pooling all finite page observations (Section 4.2.1). We evaluate the top 1,000 pages (roughly 2 GB) because differences in hot-page selection are most apparent under tight capacity. The system-level comparisons in Sections 5.1 and 5.2 show that MANTA’s runtime gains generally persist at larger fast-tier capacities. Capture is the reward of the selected pages as a percentage of the oracle top-1,000 reward. Collected is the percentage of each timestep’s hits

MANTA : Machine Learning Augmented Tiering Advisor

EuroSys ’27, April 19-23, 2027, Rabat, Morocco

0.5

2

4

6

8

Fast Memory (GB)

Fast Memory (GB)

(e) XSBench

(f) FAISS

2.11×

2.11×

2.05× 1.87×

2.11×

2.02× 1.73× 1.34× 2.11×

1.37×

8

DRAM

(d) PR-Twitter Speedup vs. CXL

1.52× 1.36× 1.57× 1.66×

2.0

1.0 0.5

6

3.0

1.36× 1.25× 1.41× 1.52×

Speedup vs. CXL

1.66×

DRAM

1.86× 1.70×

4

Fast Memory (GB)

2.5

1.5

1.22×

1.64×

Speedup vs. CXL

1.64×

1.02×

1.64×

1.52× 1.54×

1.63×

1.53× 1.53×

1.47× 1.52×

1.83× 1.72× 1.39× 2.11×

2

(c) BC-Twitter

1.29× 1.06× 1.18× 1.55×

1.21× 1.12× 1.07× 1.42×

1.05× 1.06× 1.05× 1.12×

Speedup vs. CXL

2.10×

DRAM

0.5

DRAM

2

4

6

8

DRAM

2.5 2.0 1.5 1.0 0.5

Fast Memory (GB)

(g) NAS MultiGrid

2

1.41×

8

1.0

1.17× 1.06× 0.85× 1.38×

6

1.5

1.13× 1.01× 0.81× 1.36×

4

8

3.0

2.0

1.0

6

2.0

Fast Memory (GB)

2.5

1.5

4

2.5

1.06× 0.96× 0.79× 1.27×

2

2

0.85×

DRAM

1.54× 1.30× 0.92× 1.60×

Speedup vs. CXL

2.13×

2.13×

1.37×

2.13×

1.28×

2.13×

1.98× 1.99×

8

1.0

(b) PR-Kron 1.87× 1.74× 1.55× 2.10×

1.89× 1.77× 1.52× 2.10×

1.87× 1.72× 1.49× 2.10×

1.88× 1.62× 1.48× 2.10×

Speedup vs. CXL

6

1.5

0.5

3.0

1.0 0.5

1.98× 2.01×

1.80×

(a) BC-Kron

1.5

1.99× 2.03×

4

2.0

0.78×

2

2.5

Fast Memory (GB)

3.0

2.0

1.32×

1.0 0.5

DRAM

1.98× 1.88× 1.53× 2.13×

1.5

DRAM 3.0

1.22× 1.19× 1.24× 1.40×

8

Speedup vs. CXL

1.72×

1.01×

1.69×

6

1.62× 1.64×

1.66×

1.62× 1.63×

1.60× 1.62×

4

2.0

ChOMP

1.11× 1.11× 1.08× 1.30×

2

2.5

Fast Memory (GB)

2.5

HybridTier 3.0

1.10× 1.10× 0.95× 1.27×

0.5

0.96×

1.0

0.85×

1.5

1.50× 1.38× 0.94× 1.54×

Speedup vs. CXL

2.5 2.0

ARMS

3.0

1.01× 0.91× 0.86× 1.10×

MANTA 3.0

4

6

8

DRAM

Fast Memory (GB)

(h) DuckDB

Figure 13. Speedup over simulated all-CXL execution. Higher is better. Inference Total Model build Feature gen. (𝜇s/page) ↓ (ms/step) ↓ Capture@1k ↑ Recall@1k ↑ Turnover@1k ↓ 𝑅2 ↑ Dataset Model (s) ↓ (𝜇s/page) ↓ Mean P95 Mean P95 Mean P5 Mean P5 Mean P95 ARMS 0.530 - 3.613 6.440 - 98.66 96.90 79.85 71.10 11.98 21.86 BC Twitter MANTA 455 1.753 1.437 1.648 22.067 25.336 0.914 99.07 98.78 81.95 73.16 2.92 5.70 ARMS 0.460 - 5.253 9.416 - 96.04 82.75 86.43 63.25 5.16 24.87 BC Kron MANTA 520 1.805 1.430 1.571 33.161 36.688 0.948 98.64 97.37 90.14 78.70 0.93 1.50 ARMS 0.439 - 3.703 5.472 - 99.52 99.28 44.25 36.60 28.60 33.98 PR Twitter MANTA 503 1.608 0.825 1.029 16.026 16.975 0.957 99.66 99.33 57.07 43.92 3.06 4.88 ARMS 0.476 - 5.624 8.532 - 99.66 99.47 51.85 49.70 19.09 21.10 PR Kron MANTA 726 1.649 0.791 0.948 22.970 24.117 0.966 99.71 99.58 52.30 50.74 5.57 9.60 ARMS 0.576 - 7.409 16.598 - 86.83 76.37 43.49 28.00 12.89 28.90 DuckDB MANTA 772 1.886 1.965 2.359 34.434 51.346 0.872 89.69 82.91 43.59 30.06 6.31 13.10 ARMS 0.386 - 5.706 11.288 - 94.91 70.95 49.08 29.02 10.84 19.30 XSBench MANTA 866 1.864 1.545 1.724 42.738 47.010 0.930 99.77 99.74 52.44 50.40 7.00 19.30 ARMS 0.616 - 5.289 8.009 - 91.49 76.87 17.81 14.70 25.92 27.80 FAISS MANTA 883 2.197 0.728 0.898 21.867 26.019 0.553 98.27 96.34 16.52 13.70 1.71 4.86 ARMS 0.692 - 13.230 22.911 - 97.10 95.37 3.04 1.60 30.35 55.35 MG MANTA 715 2.732 0.537 0.645 45.697 61.352 0.961 99.04 97.31 38.09 6.00 20.56 34.50

Figure 14. Prediction quality and processing costs. Ranking metrics are percentages. Arrows indicate preferred directions, and bold marks better values. that fall on the selected pages. Recall is the percentage of the oracle’s hottest positive-reward pages included in the selection, using all such pages when fewer than 1,000 exist. Capture measures how much reward the selection collects, while recall measures which pages it selects; higher capture can therefore coexist with lower recall. Both metrics average equally over steps with positive reward. Turnover is the percentage of selected pages that changed between consecutive timesteps. It measures churn in the hotpage set and thus potential migration work: lower turnover is desirable because migrations are expensive. Actual migrations also depend on the deployed rank filter (Section 4.2.7). P5 is the fifth percentile of per-step capture or recall, highlighting weaker prediction intervals; P95 is the ninety-fifth

percentile of the corresponding timing or turnover measurement. These characterize processing overhead and selection stability, not interval-level application slowdowns or memory-access tail latency. MANTA’s mean total processing time ranges from 16.026 to 45.697 ms per step, with P95 values of 16.975–61.352 ms; ARMS’s P95 total is 5.472–22.911 ms. MANTA’s P95 inference cost is 0.645–2.359 𝜇s per page. Across these traces, MANTA’s 𝑅 2 ranges from 0.553 to 0.966. It achieves higher Capture@1k and lower Turnover@1k than ARMS on all eight workloads, and higher Recall@1k on seven of eight. Only FAISS has lower recall, despite higher capture. MANTA thus generally improves hot-page selection while

6

8

10

(a) BC-Twitter

DRAM

4

6

8

10

DRAM

achieving substantially lower churn across every workload, reducing the potential need for costly migrations. The percentile results show that these benefits extend beyond the mean. MANTA improves P5 capture on all eight workloads and P5 recall on seven, with FAISS again the exception. For example, P5 capture rises from 70.95% to 99.74% on XSBench and from 82.75% to 97.37% on BC-Kron. P95 turnover is lower on seven workloads, falling from 24.87% to 1.50% on BC-Kron; XSBench is tied at 19.30% despite lower mean turnover. Thus, MANTA generally maintains better selection quality in weaker intervals while also reducing highchurn episodes. Ablation Studies

5.7.1 Cost Ablation. Figure 15 compares MANTA’s rankbased migration filter (Section 4.2.7) with an ARMS-like costbenefit check on BC-Twitter and PR-Twitter. The variants retain MANTA’s learned predictor and replace its rank filter with a check that requires predicted benefit to exceed a scaled migration cost. Lower scalers admit more candidates, while higher scalers can reject useful promotions. On BC-Twitter at 4 GB, scalers of 0.125–0.25 increase runtime by 10.03–15.92% relative to the default rank filter; higher scalers recover most of this loss. On PR-Twitter, however, scalers of 0.5–1.5 increase runtime by 7.14–9.71% at 8–10 GB. Thus, a setting that works well for one workload and capacity can hurt another. We tested all evaluated workloads and capacities on each platform. The others show similar tradeoffs or weaker sensitivity, so we present these two workloads to illustrate the variation. The rank filter reduces the need to tune a migration-cost scale for each workload and capacity. 5.7.2 Policy Ablations. Figure 16 tests virtual steps and the rank filter on BC-Twitter and PR-Twitter with 4 GB and 6 GB of fast memory on Optane, contrasting gains under tight capacity with smaller differences from ARMS at higher capacity. The panels report speedup over all-Optane execution; higher is better. Runtime ratios use arithmetic mean runtimes for each workload and capacity; the bars average per-run speedups. First, we remove the virtual-step data collection and retrain a model that uses a fixed 250 ms step size. Without

(a) BC-Twitter

5

11.25×

9.02×

10.63×

ARMS with filter

6.76×

10

1.60×

2.07×

4.64×

6

Fast Memory (GB)

(b) PR-Twitter

Figure 15. Migration filters on Linux 6.18: default MANTA ranks versus fixed cost scalers. Speedup is over all-CXL execution. Higher is better.

4.84×

4

Memory Footprint (GB)

ARMS 15

4

0.64×

0.5

5

3.71×

1.0

0.90×

1.5

10

1.47×

2.11×

2.05× 2.03× 1.97× 1.89× 1.89× 1.87×

2.02× 1.96× 1.97× 1.88× 1.87× 1.88×

1.86× 1.93× 1.97× 1.89× 1.90× 1.89×

2.0

MANTA w/o virtual step

Speedup vs. Optane

4

Memory Footprint (GB)

5.7

MANTA 15

1.27×

0.5

2.5 1.83× 1.78× 1.80× 1.86× 1.86× 1.85×

1.64×

1.0

Speedup vs. all CXL

1.51× 1.53× 1.50× 1.49× 1.50× 1.46×

1.53× 1.53× 1.52× 1.51× 1.51× 1.48×

1.48× 1.52× 1.52× 1.50× 1.49× 1.47×

1.5

1.53× 1.32× 1.39× 1.50× 1.49× 1.49×

Speedup vs. all CXL

2.5 2.0

MANTA cost ablation 0.25 DRAM

3.0

0.99×

MANTA cost ablation 0.125 MANTA cost ablation 1.0

3.0

Speedup vs. Optane

MANTA MANTA cost ablation 0.5

Johannes Freischuetz et al.

11.13×

EuroSys ’27, April 19-23, 2027, Rabat, Morocco

6

Fast Memory (GB)

(b) PR-Twitter

Figure 16. Optane ablations: replacing virtual steps with 250 ms steps, or adding MANTA’s filter to ARMS. Speedup is over all-Optane execution. Higher is better. virtual steps, mean runtime increases by 15.7% and 30.2% on BC-Twitter at 4 and 6 GB, respectively, and by 33.8% and 5.8% on PR-Twitter. At 4 GB, the fixed-step variant still achieves 1.28× and 4.41× speedups in mean runtime over ARMS on BC-Twitter and PR-Twitter, respectively; at 6 GB, it takes 24.9% and 8.4% longer than ARMS. Thus, virtual steps improve performance in all four configurations, but removing them does not eliminate every benefit of the learned policy. Second, we apply the rank filter, designed for MANTA’s predicted scores, to ARMS’s reactive scores to test whether filtering alone explains MANTA’s gains. On BC-Twitter, filtered ARMS takes 1.63× and 2.33× as long as MANTA at 4 and 6 GB, respectively, and 1.10× and 2.24× as long as unfiltered ARMS. On PR-Twitter at 6 GB, filtered ARMS takes only 1.01× as long as MANTA and 1.03× as long as unfiltered ARMS. Together, these ablations show that adding the filter alone does not reproduce MANTA’s gains, and that virtual-step features improve the learned policy on both workloads.

6

Conclusion

MANTA predicts future page usefulness to improve online memory tiering. Our interval-constrained offline optimizer, ChOMP, and trace-driven simulator expose opportunities that reactive hotness heuristics miss. A lightweight learned predictor integrated into ARMS recovers part of this headroom while retaining practical migration mechanisms. At 4 GB of fast memory, MANTA achieves geometric-mean speedups over ARMS of 1.12× and 1.08× on emulated CXL with Linux 6.2 and 6.18, and 1.69× on Optane. Its models can transfer to new inputs of the same application, but changes in access behavior require validation and potentially retraining. The remaining gap to ChOMP motivates further work on migration timing and initial placement.

Acknowledgements We thank our anonymous reviewers and shepherd for their valuable feedback. This material is based upon work supported by the National Science Foundation under Grant No. 2326576.

MANTA : Machine Learning Augmented Tiering Advisor

References [1] Dilip Abreu. 1988. On the theory of infinitely repeated games with discounting. Econometrica: Journal of the Econometric Society 56, 2 (1988), 383–396. [2] Neha Agarwal and Thomas F. Wenisch. 2017. Thermostat: Applicationtransparent Page Management for Two-tiered Main Memory. SIGPLAN Not. 52, 4 (April 2017), 631–644. doi:10.1145/3093336.3037706 [3] David Bailey, Eric Barszcz, John Barton, David Browning, Russell Carter, Leo Dagum, Rod Fatoohi, Samuel Fineberg, Paul Frederickson, Thomas Lasinski, et al. 2010. The NAS parallel benchmarks. Technical Report. Technical Report RNR-94-007, NASA Ames Research Center, (March 1994). [4] Scott Beamer, Krste Asanović, and David A. Patterson. 2015. The GAP Benchmark Suite. arXiv:1508.03619 [cs.DC] https://doi.org/10.48550/ arXiv.1508.03619 [5] L. A. Belady. 1966. A study of replacement algorithms for a virtualstorage computer. IBM Systems Journal 5, 2 (1966), 78–101. doi:10. 1147/sj.52.0078 [6] Daniel S. Berger, Nathan Beckmann, and Mor Harchol-Balter. 2018. Practical Bounds on Optimal Caching with Variable Object Sizes. Proceedings of the ACM on Measurement and Analysis of Computing Systems 2, 2 (June 2018), 1–38. doi:10.1145/3224427 [7] Daniel S. Berger, Karthik Kumar, Midhul Vuppalapati, Chet Douglas, Jesse Sathre, Ian Robinson, Prateek Tandon, and Mark D. Hill. 2026. CXL in Cloud Practice: Practical Lessons for Incrementally Scaling Deployment. IEEE Trans. Comput. 75, 4 (2026), 1234–1246. doi:10.1109/ TC.2026.3667614 [8] Simon Boehm. 2024. lleaves. GitHub. https://github.com/siboehm/ lleaves [9] Juneseo Chang, Wanju Doh, Yaebin Moon, Eojin Lee, and Jung Ho Ahn. 2024. IDT: Intelligent Data Placement for Multi-tiered Main Memory with Reinforcement Learning. In Proceedings of the 33rd International Symposium on High-Performance Parallel and Distributed Computing (Pisa, Italy) (HPDC ’24). Association for Computing Machinery, New York, NY, USA, 69–82. doi:10.1145/3625549.3658659 [10] Debendra Das Sharma, Robert Blankenship, and Daniel Berger. 2024. An Introduction to the Compute Express Link (CXL) Interconnect. ACM Comput. Surv. 56, 11, Article 290 (July 2024), 37 pages. doi:10. 1145/3669900 [11] Thaleia Dimitra Doudali, Sergey Blagodurov, Abhinav Vishnu, Sudhanva Gurumurthi, and Ada Gavrilovska. 2019. Kleio: A Hybrid Memory Page Scheduler with Machine Intelligence. In Proceedings of the 28th International Symposium on High-Performance Parallel and Distributed Computing (Phoenix, AZ, USA) (HPDC ’19). Association for Computing Machinery, New York, NY, USA, 37–48. doi:10.1145/ 3307681.3325398 [12] Thaleia Dimitra Doudali and Ada Gavrilovska. 2022. Coeus: Clustering (A)like Patterns for Practical Machine Intelligent Hybrid Memory Management. In 2022 22nd IEEE International Symposium on Cluster, Cloud and Internet Computing (CCGrid). IEEE, Piscataway, NJ, USA, 615–624. doi:10.1109/CCGrid54584.2022.00071 [13] Thaleia Dimitra Doudali and Ada Gavrilovska. 2023. Cronus: Computer Vision-based Machine Intelligent Hybrid Memory Management. In Proceedings of the 2022 International Symposium on Memory Systems (Washington, DC, USA) (MEMSYS ’22). Association for Computing Machinery, New York, NY, USA, Article 10, 11 pages. doi:10.1145/ 3565053.3565063 [14] Thaleia Dimitra Doudali, Daniel Zahka, and Ada Gavrilovska. 2021. Cori: Dancing to the Right Beat of Periodic Data Movements over Hybrid Memory Systems. In 2021 IEEE International Parallel and Distributed Processing Symposium (IPDPS). IEEE Computer Society, Los Alamitos, CA, USA, 350–359. doi:10.1109/IPDPS49936.2021.00043 [15] Matthijs Douze, Alexandr Guzhva, Chengqi Deng, Jeff Johnson, Gergely Szilvasy, Pierre-Emmanuel Mazaré, Maria Lomeli,

EuroSys ’27, April 19-23, 2027, Rabat, Morocco Lucas Hosseini, and Hervé Jégou. 2024. The Faiss Library. arXiv:2401.08281 [cs.LG] https://arxiv.org/abs/2401.08281 [16] Subramanya R. Dulloor, Amitabha Roy, Zheguang Zhao, Narayanan Sundaram, Nadathur Satish, Rajesh Sankaran, Jeff Jackson, and Karsten Schwan. 2016. Data tiering in heterogeneous memory systems. In Proceedings of the Eleventh European Conference on Computer Systems (London, United Kingdom) (EuroSys ’16). Association for Computing Machinery, New York, NY, USA, Article 15, 16 pages. doi:10.1145/ 2901318.2901344 [17] Dmitry Duplyakin, Robert Ricci, Aleksander Maricq, Gary Wong, Jonathon Duerig, Eric Eide, Leigh Stoller, Mike Hibler, David Johnson, Kirk Webb, Aditya Akella, Kuangching Wang, Glenn Ricart, Larry Landweber, Chip Elliott, Michael Zink, Emmanuel Cecchet, Snigdhaswin Kar, and Prabodh Mishra. 2019. The Design and Operation of CloudLab. In 2019 USENIX Annual Technical Conference (USENIX ATC 19). USENIX Association, Renton, WA, 1–14. https: //dl.acm.org/doi/10.5555/3358807.3358809 [18] Pouya Esmaili-Dokht, Francesco Sgherzi, Valéria Soldera Girelli, Isaac Boixaderas, Mariana Carmin, Alireza Monemi, Adrià Armejach, Estanislao Mercadal, Germán Llort, Petar Radojković, Miquel Moreto, Judit Giménez, Xavier Martorell, Eduard Ayguadé, Jesus Labarta, Emanuele Confalonieri, Rishabh Dubey, and Jason Adlard. 2024. A Mess of Memory System Benchmarking, Simulation and Application Profiling. In 2024 57th IEEE/ACM International Symposium on Microarchitecture (MICRO). IEEE, Piscataway, NJ, USA, 136–152. doi:10.1109/micro61859.2024.00020 [19] Zhiyuan Guo, Zijian He, and Yiying Zhang. 2023. Mira: A ProgramBehavior-Guided Far Memory System. In Proceedings of the 29th Symposium on Operating Systems Principles (Koblenz, Germany) (SOSP ’23). Association for Computing Machinery, New York, NY, USA, 692–708. doi:10.1145/3600006.3613157 [20] Gurobi Optimization, LLC. 2026. Gurobi Optimizer Reference Manual. https://www.gurobi.com [21] Alan J. Hoffman and Joseph B. Kruskal. 1956. Integral Boundary Points of Convex Polyhedra. In Linear Inequalities and Related Systems, Harold W. Kuhn and Albert W. Tucker (Eds.). Princeton University Press, Princeton, NJ, USA. [22] Frank Hutter, Holger H. Hoos, and Kevin Leyton-Brown. 2011. Sequential Model-Based Optimization for General Algorithm Configuration. In Learning and Intelligent Optimization, Carlos A. Coello Coello (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 507–523. https://doi.org/10.1007/978-3-642-25566-3_40. [23] Guolin Ke, Qi Meng, Thomas Finley, Taifeng Wang, Wei Chen, Weidong Ma, Qiwei Ye, and Tie-Yan Liu. 2017. LightGBM: A Highly Efficient Gradient Boosting Decision Tree. In Advances in Neural Information Processing Systems 30. Curran Associates, Inc., Red Hook, NY, USA, 3146–3154. https://papers.nips.cc/paper/6907-lightgbm-ahighly-efficient-gradient-boosting-decision-tree [24] Taehyung Lee, Sumit Kumar Monga, Changwoo Min, and Young Ik Eom. 2023. MEMTIS: Efficient Memory Tiering with Dynamic Page Classification and Page Size Determination. In Proceedings of the 29th Symposium on Operating Systems Principles (Koblenz, Germany) (SOSP ’23). Association for Computing Machinery, New York, NY, USA, 17–34. doi:10.1145/3600006.3613167 [25] Huaicheng Li, Daniel S. Berger, Lisa Hsu, Daniel Ernst, Pantea Zardoshti, Stanko Novakovic, Monish Shah, Samir Rajadnya, Scott Lee, Ishwar Agarwal, Mark D. Hill, Marcus Fontoura, and Ricardo Bianchini. 2023. Pond: CXL-Based Memory Pooling Systems for Cloud Platforms. In Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2 (Vancouver, BC, Canada) (ASPLOS 2023). Association for Computing Machinery, New York, NY, USA, 574–587. doi:10.1145/3575693.3578835

EuroSys ’27, April 19-23, 2027, Rabat, Morocco [26] Jinshu Liu, Hamid Hadian, Yuyue Wang, Daniel S. Berger, Marie Nguyen, Xun Jian, Sam H. Noh, and Huaicheng Li. 2025. Systematic CXL Memory Characterization and Performance Analysis at Scale. In Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2 (Rotterdam, Netherlands) (ASPLOS ’25). Association for Computing Machinery, New York, NY, USA, 1203–1217. doi:10.1145/3676641.3715987 [27] Jinshu Liu, Hamid Hadian, Hanchen Xu, and Huaicheng Li. 2025. Tiered Memory Management Beyond Hotness. In Proceedings of the USENIX Symposium on Operating Systems Design and Implementation (OSDI ’25). USENIX Association, USA, 731–747. https://www.usenix. org/system/files/osdi25-liu.pdf [28] Hasan Al Maruf, Hao Wang, Abhishek Dhanotia, Johannes Weiner, Niket Agarwal, Pallab Bhattacharya, Chris Petersen, Mosharaf Chowdhury, Shobhit Kanaujia, and Prakash Chauhan. 2023. TPP: Transparent Page Placement for CXL-Enabled Tiered-Memory. In Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 3 (ASPLOS ’23). ACM, New York, NY, USA, 742–755. doi:10.1145/3582016.3582063 [29] Diego Moura, Vinicius Petrucci, and Daniel Mossé. 2021. Learning to Rank Graph-based Application Objects on Heterogeneous Memories. In Proceedings of the International Symposium on Memory Systems (MEMSYS ’21). Association for Computing Machinery, New York, NY, USA, Article 5, 14 pages. doi:10.1145/3488423.3519324 [30] Arvind Neelakantan, Tao Xu, Raul Puri, Alec Radford, Jesse Michael Han, Jerry Tworek, Qiming Yuan, Nikolas Tezak, Jong Wook Kim, Chris Hallacy, Johannes Heidecke, Pranav Shyam, Boris Power, Tyna Eloundou Nekoul, Girish Sastry, Gretchen Krueger, David Schnurr, Felipe Petroski Such, Kenny Hsu, Madeleine Thompson, Tabarak Khan, Toki Sherbakov, Joanne Jang, Peter Welinder, and Lilian Weng. 2022. Text and Code Embeddings by Contrastive Pre-Training. arXiv:2201.10005 [cs.CL] https://arxiv.org/abs/2201.10005 [31] Lawrence Page, Sergey Brin, Rajeev Motwani, and Terry Winograd. 1999. The PageRank Citation Ranking: Bringing Order to the Web. Technical Report 1999-66. Stanford InfoLab. http://ilpubs.stanford.edu: 8090/422/ Previous number = SIDL-WP-1999-0120. [32] Meikel Poess and Chris Floyd. 2000. New TPC benchmarks for decision support and web commerce. ACM Sigmod Record 29, 4 (2000), 64–71. http://doi.org/10.1145/369275.369291 [33] Mark Raasveldt and Hannes Muehleisen. 2026. DuckDB. DuckDB. https://github.com/duckdb/duckdb [34] Luiz E. Ramos, Eugene Gorbatov, and Ricardo Bianchini. 2011. Page placement in hybrid memory systems. In Proceedings of the International Conference on Supercomputing (Tucson, Arizona, USA) (ICS ’11). Association for Computing Machinery, New York, NY, USA, 85–95. doi:10.1145/1995896.1995911 [35] Amanda Raybuck, Tim Stamler, Wei Zhang, Mattan Erez, and Simon Peter. 2021. HeMem: Scalable Tiered Memory Management for Big Data Applications and Real NVM. In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles (Virtual Event, Germany) (SOSP ’21). Association for Computing Machinery, New York, NY, USA, 392–407. doi:10.1145/3477132.3483550 [36] Divyanshu Saxena, Jiayi Chen, Sujay Yadalam, Yeonju Ro, Rohit Dwivedula, Eric H. Campbell, Aditya Akella, Christopher J. Rossbach, and Michael Swift. 2025. How I learned to stop worrying and love learned OS policies. In Proceedings of the 2025 Workshop in Hot Topics in Operating Systems (HOTOS ’25). Association for Computing Machinery, New York, NY, USA, 7 pages. doi:10.1145/3713082.3730384 [37] Kevin Song, Jiacheng Yang, Zixuan Wang, Jishen Zhao, Sihang Liu, and Gennady Pekhimenko. 2025. HybridTier: an Adaptive and Lightweight CXL-Memory Tiering System. In Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 3 (ASPLOS ’25). Association for Computing Machinery, New York, NY, USA, 112–128.

Johannes Freischuetz et al. doi:10.1145/3676642.3736119 [38] Zhenyu Song, Daniel S. Berger, Kai Li, and Wyatt Lloyd. 2020. Learning relaxed Belady for content distribution network caching. In Proceedings of the 17th Usenix Conference on Networked Systems Design and Implementation (Santa Clara, CA, USA) (NSDI’20). USENIX Association, USA, 529–544. [39] Wenda Tang, Yiduo Wang, Yanwen Wang, and Jie Wu. 2025. Leave No One Behind: Fair and Efficient Tiered Memory Management for MultiApplications. In Proceedings of the 54th International Conference on Parallel Processing (ICPP ’25). Association for Computing Machinery, New York, NY, USA, 699–709. doi:10.1145/3754598.3754626 [40] John R Tramm, Andrew R Siegel, Tanzima Islam, and Martin Schulz. 2014. XSBench - The Development and Verification of a Performance Abstraction for Monte Carlo Reactor Analysis. In PHYSOR 2014 - The Role of Reactor Physics toward a Sustainable Future. Japan Atomic Energy Agency, Kyoto, 12 pages. https://www.mcs.anl.gov/papers/ P5064-0114.pdf [41] Shivaram Venkataraman, Erik Bodzsar, Indrajit Roy, Alvin AuYoung, and Robert S. Schreiber. 2013. Presto: Distributed Machine Learning and Graph Processing with Sparse Matrices. In Proceedings of the 8th ACM European Conference on Computer Systems (EuroSys ’13). Association for Computing Machinery, New York, NY, USA, 197–210. doi:10.1145/2465351.2465371 [42] Midhul Vuppalapati and Rachit Agarwal. 2024. Tiered Memory Management: Access Latency is the Key!. In Proceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles (Austin, TX, USA) (SOSP ’24). Association for Computing Machinery, New York, NY, USA, 79–94. doi:10.1145/3694715.3695968 [43] Johannes Weiner, Niket Agarwal, Dan Schatzberg, Leon Yang, Hao Wang, Blaise Sanouillet, Bikash Sharma, Tejun Heo, Mayank Jain, Chunqiang Tang, and Dimitrios Skarlatos. 2022. TMO: transparent memory offloading in datacenters. In Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (Lausanne, Switzerland) (ASPLOS ’22). Association for Computing Machinery, New York, NY, USA, 609–621. doi:10.1145/3503222.3507731 [44] Wm. A. Wulf and Sally A. McKee. 1995. Hitting the memory wall: implications of the obvious. SIGARCH Comput. Archit. News 23, 1 (March 1995), 20–24. doi:10.1145/216585.216588 [45] Lingfeng Xiang, Zhen Lin, Weishu Deng, Hui Lu, Jia Rao, Yifan Yuan, and Ren Wang. 2024. NOMAD: non-exclusive memory tiering via transactional page migration. In Proceedings of the 18th USENIX Conference on Operating Systems Design and Implementation (Santa Clara, CA, USA) (OSDI’24). USENIX Association, USA, Article 2, 17 pages. [46] Lingfeng Xiang, Xingsheng Zhao, Jia Rao, Song Jiang, and Hong Jiang. 2022. Characterizing the performance of intel optane persistent memory: a close look at its on-DIMM buffering. In Proceedings of the Seventeenth European Conference on Computer Systems (Rennes, France) (EuroSys ’22). Association for Computing Machinery, New York, NY, USA, 488–505. doi:10.1145/3492321.3519556 [47] Dong Xu, Junhee Ryu, Jinho Baek, Kwangsik Shin, Pengfei Su, and Dong Li. 2024. FlexMem: Adaptive Page Profiling and Migration for Tiered Memory. In 2024 USENIX Annual Technical Conference (USENIX ATC 24). USENIX Association, USA, 817–833. [48] Sujay Yadalam, Konstantinos Kanellis, Michael Swift, and Shivaram Venkataraman. 2025. ARMS: Adaptive and Robust Memory Tiering System. doi:10.48550/arXiv.2508.04417 arXiv:2508.04417 [cs.OS] [49] Zi Yan, Daniel Lustig, David Nellans, and Abhishek Bhattacharjee. 2019. Nimble Page Management for Tiered Memory Systems. In Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems (Providence, RI, USA) (ASPLOS ’19). Association for Computing Machinery, New York, NY, USA, 331–345. doi:10.1145/3297858.3304024

MANTA : Machine Learning Augmented Tiering Advisor [50] Jian Yang, Juno Kim, Morteza Hoseinzadeh, Joseph Izraelevitz, and Steve Swanson. 2020. An Empirical Guide to the Behavior and Use of Scalable Persistent Memory. In 18th USENIX Conference on File and Storage Technologies (FAST 20). USENIX Association, Santa Clara, CA, 169–182. https://www.usenix.org/conference/fast20/presentation/ yang [51] Xinjun Yang, Yingqiang Zhang, Hao Chen, Feifei Li, Gerry Fan, Yang Kong, Bo Wang, Jing Fang, Yuhui Wang, Tao Huang, Wenpu Hu, Jim Kao, and Jianping Jiang. 2025. Unlocking the Potential of CXL for Disaggregated Memory in Cloud-Native Databases. In Companion of the 2025 International Conference on Management of Data (Berlin, Germany) (SIGMOD/PODS ’25). Association for Computing Machinery,

EuroSys ’27, April 19-23, 2027, Rabat, Morocco New York, NY, USA, 689–702. doi:10.1145/3722212.3724460 [52] Xinyue Yi, Hongchao Du, Yu Wang, Jie Zhang, Qiao Li, and Chun Jason Xue. 2025. ArtMem: Adaptive Migration in Reinforcement Learning-Enabled Tiered Memory. In Proceedings of the 52nd Annual International Symposium on Computer Architecture (ISCA ’25). Association for Computing Machinery, New York, NY, USA, 405–418. doi:10.1145/3695053.3731001 [53] Lei Zhang, Reza Karimi, Irfan Ahmad, and Ymir Vigfusson. 2020. Optimal Data Placement for Heterogeneous Cache, Memory, and Storage Systems. Proc. ACM Meas. Anal. Comput. Syst. 4, 1, Article 06 (May 2020), 27 pages. doi:10.1145/3379472

Related documents

• MANTA: Machine Learning Augmented Tiering Advisor#1155649
• Reshaping Rollout Workloads for Asynchronous RL Post-Training on Heterogeneous Accelerators#1132100
• Reshaping Rollout Workloads for Asynchronous RL Post-Training on Heterogeneous Accelerators#1122264
• Graph Transformations for Memory Peak Minimization by Scheduling#427373
• Exploring the Efficiency of 3D-Stacked AI Chip Architecture for LLM Inference with VOXEL#1070816