CXLAimPod: Duplex-Aware CXL Memory Scheduler
- CXLAimPod is a duplex-aware Linux memory scheduler that leverages full-duplex CXL channels to balance mixed read/write workloads.
- It integrates eBPF-based observability with sched_ext and cgroup hints to adaptively co-schedule tasks for improved bandwidth and reduced turnaround penalties.
- Evaluation results show significant performance gains—up to 195.9% in sequential workloads—highlighting the importance of workload mix and concurrency in CXL systems.
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 (Yang et al., 21 Aug 2025).
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 (Yang et al., 21 Aug 2025).
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 (Yang et al., 21 Aug 2025).
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 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 (Yang et al., 21 Aug 2025).
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 (Yang et al., 21 Aug 2025).
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 (Yang et al., 21 Aug 2025).
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 (Yang et al., 21 Aug 2025).
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- KV entries needed by each layer, rather than bulk-prefetching the entire prefix KV cache (Ma et al., 18 Jun 2026). 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.