---
title: 'CXLAimPod: Duplex-Aware CXL Memory Scheduler'
url: https://www.emergentmind.com/topics/cxlaimpod
type: topic
---

# CXLAimPod: Duplex-Aware CXL Memory Scheduler

Searching arXiv for the specified paper and a closely related CXL-based LLM memory system for contextual grounding.
CXLAimPod is a duplex-aware Linux memory scheduling framework for CXL-attached memory. It is designed for mixed read-write workloads in which conventional DDR5’s half-duplex bus incurs turnaround penalties, while Compute Express Link (CXL) exposes full-duplex channels with separate transmit and receive paths. The framework’s stated purpose is to bridge the software-hardware gap by making scheduling aware of read/write asymmetry, using system support that includes cgroup-based hints for application-aware optimization. Implemented within Linux via eBPF and integrated with `sched_ext`, CXLAimPod is evaluated on Redis, LLM text generation, and vector databases, where it reports improvements that depend strongly on access pattern and concurrency [2508.15980].

## 1. Motivation and problem formulation

The framework is motivated by the observation that modern AI-era and datacenter workloads increasingly generate interleaved memory traffic. The workload classes explicitly identified include Redis, LLM inference, vector search, databases, and graph workloads. In this setting, DDR5 is characterized as a half-duplex architecture in which reads and writes share a bus, and switching direction incurs turnaround penalties of **15–20 cycles**, or about **11–15 ns at DDR5-6400**. The reported consequence is that DDR5 bandwidth remains relatively flat across read-write ratios, varying only **26%** overall, from **153 to 189 GB/s**, because the memory controller batches requests to reduce turnaround overhead [2508.15980].

CXL is presented as architecturally different because it uses full-duplex channels with separate TX and RX paths. The paper’s characterization states that CXL can achieve **55–61% bandwidth improvement at balanced read-write ratios** relative to pure-write or unbalanced cases, whereas DDR5 remains nearly flat. The central claim is therefore not merely that CXL is another memory tier, but that it creates a scheduling opportunity that conventional OS schedulers, memory controllers, and NUMA policies do not exploit because they were designed for half-duplex memory systems.

The problem statement follows directly from this mismatch. Existing software tends to reduce read/write interleaving, while CXL benefits from it. CXLAimPod addresses that mismatch by shaping task placement so that the aggregate request stream more closely matches the hardware’s bidirectional capability.

## 2. Duplex-aware scheduling model

CXLAimPod’s scheduling model is process- and task-centric. Rather than replacing the base scheduler, it augments existing Linux scheduling with CXL-aware placement and is designed to work with existing NUMA placement rather than replacing it. The division of labor is explicit: NUMA decides where memory lives, while CXLAimPod fine-tunes which tasks should run together so that the combined memory stream becomes more balanced for CXL [2508.15980].

The framework has three stated parts: **observability infrastructure**, **pluggable policy engine**, and **system integration interfaces** for cgroups, memory controllers, and Linux scheduler hooks. Its key scheduling action is `duplex_select_cpu`, which inspects a task’s memory access profile, especially its read/write ratio, and chooses CPU placement to improve aggregate balance. If a CPU cluster is dominated by reads, write-heavy tasks are colocated there so that the combined stream becomes more balanced.

The concrete policy described as the production policy is a **time-series predictive policy**. It analyzes recent history using a sliding window, detects phase changes, and predicts upcoming access mix. Oversubscription is detected when **average running threads > 1.5 per core** and **CPU utilization > 85%**. The paper gives the complexity of the scheduling iteration as **$O(n \log n + m)$** for oversubscription detection and task placement.

The framework is explicitly pluggable. The design mentions **threshold-based handling**, **EWMA-style trend analysis**, **adaptive time slicing**, **oversubscription detection**, and **dynamic policy switching**. This indicates that the system is not tied to a single heuristic, although the time-series predictive policy is the concrete policy described in detail.

## 3. cgroup hints, observability, and Linux integration

A major design point is the use of **cgroups** as the hint interface. The paper states that pure observability is insufficient for **bursty workloads**, **short-lived processes**, and **fast phase changes**. Cgroups are used because they are a **standard Linux interface**, **secure**, **compatible with Docker/Kubernetes**, and **hierarchical**, allowing hints to be set at system, container, or process scope. These hints let applications or administrators indicate whether a workload is **read-heavy**, **write-heavy**, **balanced**, or **latency-sensitive**, allowing the scheduler either to co-schedule for duplex benefit or to reduce intervention to avoid overhead [2508.15980].

The implementation is an **eBPF-based scheduler** integrated with **Linux 6.14+ `sched_ext`**, and the paper emphasizes safe deployability without kernel modifications. The observability stack includes **eBPF uprobes** for function entry and exit instrumentation, `bpf_perf_event_read_value` for PMU access, **`sched_switch` tracepoint programs** for thread-level attribution, **BPF hash maps and array maps** for context and counters, **per-CPU ring buffers** to reduce contention, and **memory-mapped BPF maps** for userspace aggregation.

The paper also introduces the **CXL Analysis Context (CAX)** abstraction. CAX supports profiling at **system level**, **process level**, **thread level**, **function/code segment level**, and **VM level**. This enables attribution of CXL bandwidth to specific execution contexts rather than only to the machine as a whole.

Two eBPF programs are identified as core scheduler components. **`duplex_select_cpu`** selects a CPU based on task memory profile and current cluster mix. **`duplex_enqueue`** updates queue statistics, tracks read/write queue depths, and triggers rebalancing when thresholds are exceeded. The system is reported to have been integrated with more than **20 `sched_ext` schedulers**, including `scx_bpfland`, `scx_lavd`, `scx_rusty`, `scx_nest`, and `scx_layered`. The deployment focus is deliberately narrow: **CXL memory on NUMA node 3 (512 GB)** is used to isolate duplex scheduling effects from full NUMA placement optimization.

## 4. Hardware characterization and bandwidth behavior

The characterization platform comprises a **single-socket Intel Xeon 6 6787P (Granite Rapids)** with **86 cores**, **2.0 GHz base**, and **3.8 GHz turbo**; a **128 GB DDR5 baseline across two NUMA nodes**; and two CXL memory expanders of **256 GB** and **512 GB**, connected via **PCIe Gen5 x16, CXL 2.0**. Total memory is **896 GB**. Experiments use **4–172 threads**, **1 GB and 64 GB buffers**, **random and sequential patterns**, **read/write ratios from 0–100%**, and **3-run averages** with PMU and device counters [2508.15980].

The reported bandwidth findings establish the hardware opportunity targeted by CXLAimPod. For **random access with 64 GB buffers**, DDR5 averages **166.7 GB/s**. The **256 GB CXL** device reaches **27.8 GB/s**, or **17%** of DDR5, and the **512 GB CXL** device reaches **48.6 GB/s**, or **29%** of DDR5. These values show that raw CXL bandwidth remains below local DDR5 bandwidth, but the paper’s argument is about exploiting CXL’s duplex behavior rather than matching DDR5’s latency or peak locality.

At balanced read-write ratios, the duplex effect is explicit. For the **256 GB CXL** device, bandwidth is **34.4 GB/s at 50% reads** versus **22.2 GB/s pure writes**, a **55% improvement**. For the **512 GB CXL** device, bandwidth is **57.8 GB/s at 55% reads** versus **35.9 GB/s pure writes**, a **61% improvement**. By contrast, DDR5 varies only from **153–189 GB/s** over all ratios.

Additional characterization refines the picture. CXL write throughput is **74–93%** of read throughput, depending on device. **Random access** utilizes CXL duplexing better than **sequential access**. For the **512 GB CXL** device, random access peaks at **65% reads** with **62.9 GB/s**, while sequential access peaks at **95% reads** with **197.0 GB/s**. Random access maintains **92% of peak bandwidth** at a **50/50** mix, while sequential access falls to **37% of peak** at the same mix. Sequential reads improve from **48.8 GB/s random** to **186.6 GB/s**, a **282%** improvement, while sequential writes improve from **36.2 GB/s** to **59.0 GB/s**, a **63%** improvement.

Thread scaling is likewise distinctive. **DDR5 peaks at 64 threads**, whereas **CXL peaks at 172 threads**; the characterization states that CXL needs more concurrency because of higher latency, and that the **172-thread recommendation is nearly 3× the DDR5 requirement**. This supports the paper’s view that duplex-aware scheduling is most relevant when enough concurrency exists to fill the bidirectional link.

## 5. Workload evaluation

The evaluation environment uses **Ubuntu 25.04**, **Linux 6.14.0-27-generic**, a baseline of **default Linux EEVDF / CFS without CXL-specific optimization**, and a best configuration of **CXLAimPod with time-series predictive policy**, with **172 threads** and **NUMA binding to node 3 CXL memory**. Many tests use **3-run averages**, and Redis error bars come from **10 runs** [2508.15980].

The microbenchmark results show strong pattern dependence. The paper reports **up to 195.9% improvement** over Linux CFS on sequential patterns, **95.8% average improvement** across all sequential microbenchmark ratios, **1.2% average improvement** for random patterns, **1.8% max improvement** for random patterns, and **48.5% average improvement** across all tested microbenchmark configurations. The disparity between sequential and random cases is presented as evidence that predictability and balance matter to the scheduler’s effectiveness.

| Workload | Headline result | Additional note |
|---|---:|---|
| Redis | **7.4%** average throughput improvement | P99 latency improves **6%** on average |
| LLM text generation | **71.6%** improvement | Prompt processing improves **1.8%** |
| Vector database | **9.1%** throughput improvement | Average latency reduced **8.3%** |

For **Redis 7.0** with `memtier_benchmark`, **320 concurrent clients**, a **256 GB dataset on CXL memory**, and **five access patterns**, the results are mixed. Read-heavy **1:10 SET:GET** throughput **drops 22%**, from **4.61M** to **3.60M ops/sec**. Write-heavy **10:1** throughput **drops 16%**, from **1.91M** to **1.61M ops/sec**. In contrast, **pipelined 16-command batches** improve **69%**, from **1.11M** to **1.87M ops/sec**; **sequential access** improves **150%**, from **0.77M** to **1.92M ops/sec**; and **Gaussian random** improves **14%**, from **0.37M** to **0.42M ops/sec**. Latency results are similarly pattern-sensitive: read-heavy P99 latency shows a **15% reduction**, **4.40 ms → 3.76 ms**; write-heavy shows a **4% increase** to **5.05 ms**; pipelined improves **37%**, **7.17 ms → 4.51 ms**; sequential shows a **7% reduction**, **4.77 ms → 4.42 ms**; and Gaussian random shows a **16% increase**, **9.98 ms → 11.55 ms**. The best-benefiting Redis workloads are identified as **sequential patterns** and **pipelined balanced patterns**.

For **LLM inference**, the evaluated models are **LLAMA3 70B** and **Deepseek V3-0324 671B**. The access-pattern characterization reports that **attention** is about **85% reads**, while **feed-forward layers** are about **60% reads / 40% writes**. The measured outcome is that **prompt processing** reaches **140.70 tokens/s** with CXLAimPod versus **138.12 tokens/s** with Linux CFS, a **1.8% improvement**, while **text generation** reaches **2.42 tokens/s** versus **1.41 tokens/s**, a **71.6% improvement**. The interpretation given in the data is that prompt loading is mostly read-heavy and therefore benefits little, whereas generation has alternating phases and benefits strongly from co-scheduling.

For **vector databases**, the workload uses **PyVSAG**, an **HNSW index**, **50,000 128-dimensional vectors**, and **1,000 queries**. Throughput increases from **3,607 QPS** to **3,935 QPS**, a **9.1% improvement**, and average latency decreases from **276.4 μs** to **253.4 μs**, an **8.3% reduction**.

## 6. Limitations, misconceptions, and relation to CXL-based AI memory systems

The paper’s own results constrain the scope of its claims. CXLAimPod is most effective when workload phases are **mixed or balanced**; it can hurt **read-heavy workloads**, **write-heavy workloads**, and **unpredictable random patterns**. The Redis results include clear regressions in unidirectional cases, which directly contradicts the misconception that duplex-aware scheduling is uniformly beneficial [2508.15980].

A second misconception is that the framework makes CXL intrinsically lower-latency than DDR5. The paper explicitly states that **CXL has higher raw latency than DDR5**, with **CXL: 130–200 ns** and **DDR5: 75–85 ns**. CXLAimPod is therefore not presented as a mechanism for beating DDR5 on pure latency; it is an optimization for **bandwidth utilization and concurrency**. The dependence on concurrency is explicit in the characterization, which finds that CXL may need up to **172 threads** to saturate bandwidth.

Deployment assumptions are also narrow. The implementation targets **Linux 6.14+**, requires **`sched_ext` support**, an **eBPF-enabled kernel**, and **CXL memory exposed as memory-only NUMA nodes**. Its evaluation focuses on **NUMA node 3**, and the paper states that duplex scheduling is **orthogonal to NUMA placement** rather than a replacement for it. The cgroup hint mechanism broadens applicability, but the system still depends on useful hints or reliable profiling, and the text acknowledges that purely reactive observability is insufficient for short-lived or bursty workloads.

In the broader CXL literature, CXLAimPod represents one line of system design: exploiting CXL’s **full-duplex channels** through software scheduling. A distinct line appears in sparse-attention LLM serving, where SAC uses a **CXL-based memory-semantic disaggregated KV cache** to fetch only the runtime-selected **top-$k$** KV entries needed by each layer, rather than bulk-prefetching the entire prefix KV cache [2606.19746]. This suggests that CXL is being used in at least two technically different ways in AI systems: as a substrate whose **duplexity** can be exposed by scheduler policy, and as a memory fabric whose **cache-line granularity load/store semantics** can support fine-grained remote access. CXLAimPod belongs to the former category, with its principal contribution residing in Linux scheduling, cgroup hints, and eBPF-based observability rather than in a new memory device or a new disaggregated memory protocol.

Source: https://www.emergentmind.com/topics/cxlaimpod