CXL Memory Pooling: The Stranded DRAM Problem

Q: What is CXL memory pooling and why does it matter?

CXL (Compute Express Link) memory pooling is a way to share DRAM across multiple servers instead of hard-wiring it to one CPU. CXL is a cache-coherent interconnect built on the PCIe physical layer that lets a processor address memory living outside its own DIMM slots — on an expander card or in a shared pool behind a CXL switch — as ordinary, byte-addressable RAM. Pooling matters because in conventional servers, memory is captive to the socket that owns it: you size each machine for its heaviest tenant, and the unused remainder cannot be lent to a neighbouring server that is short. Microsoft’s Pond study of Azure measured the cost of this — up to 25% of DRAM stranded and around half of all VMs using less than half their rented memory. By pooling the stranded remainder across a handful of hosts and assigning it on demand, operators can rent memory they already own rather than buying more, which Pond reports cuts DRAM cost by about 7% and total server cost by roughly 3.5%. At hyperscale those percentages represent very large absolute savings on hardware that was otherwise sitting idle and drawing power.

Q: Why is so much datacenter memory stranded in the first place?

Memory is stranded because it is provisioned per server for the worst case but consumed per workload in bursts, and because memory bound to one CPU socket physically cannot be reassigned to another. When a hypervisor allocates cores from a server to virtual machines, it eventually runs out of cores while DRAM remains — but that leftover DRAM cannot be rented, because there are no free cores to attach it to. Microsoft’s Pond research on Azure quantified this: up to 25% of DRAM becomes stranded as cores get allocated away, and about 50% of all VMs touch less than 50% of the memory they rented. Neither figure is a tuning mistake that better configuration would fix; they are the structural consequence of two facts — you must size each box so its fullest tenant never runs out of memory, so every box carries slack; and memory is welded to its socket, so one server’s slack cannot cover another server’s shortfall. The result is a large, paid-for, powered pool of RAM that is simultaneously present and unusable. CXL attacks exactly this by letting that captive memory become a shared, reassignable resource.

Q: What is the difference between CXL memory expansion, pooling and sharing?

These are three distinct capabilities gated by the CXL specification version, and conflating them is the most common architectural error. Expansion (CXL 1.0/1.1) simply adds more memory to a single host over spare PCIe lanes — it gives one server extra capacity or bandwidth, with no ability to share that memory with any other machine. Pooling (introduced in CXL 2.0, with single-level switching) lets one physical pool of DRAM be partitioned across roughly sixteen hosts, with each slice assigned to a host on demand; at any given moment a given region belongs to one host, but the allocation can move over time to wherever memory is short. This is what reclaims stranded capacity. Sharing (introduced in CXL 3.0, over a PCIe 6.0 fabric supporting up to 4,096 endpoints) goes further and lets multiple hosts coherently see the same memory region simultaneously, enabling genuinely new patterns like a common in-memory dataset that several servers read at once. Pooling solves the stranding problem that most operators actually have; sharing solves a harder, newer problem that fewer workloads need. Matching the version to the pattern you require — rather than reaching for the highest number — is the decision that matters.

Q: What is the latency penalty of CXL-attached memory versus local DRAM?

CXL memory is meaningfully slower to reach than local DRAM, and that gap is the single most important factor in deciding whether it fits a workload. Measurements across real CXL devices put access latency in the range of 140 to 410 nanoseconds; a good ASIC-based controller sits around 170 to 250 nanoseconds, while local DRAM is roughly 80 to 140 nanoseconds. Microsoft’s Pond work models the practical cost of a pool at about 70 to 90 nanoseconds added over same-NUMA-node DRAM — in other words, roughly one extra NUMA hop’s worth of latency, and sometimes a bit more. Just as important as the median is the tail: CXL memory shows higher and less stable p99 latency than socket-local or NUMA memory, because it traverses a switch and a longer path. For a latency-bound workload such as an online transaction processing database doing heavy pointer-chasing, or a low-latency key-value store, every one of those nanoseconds shows up in the p99 and can breach an SLA. For capacity-bound or bandwidth-bound workloads that tolerate a NUMA hop — analytics, large caches, batch inference over big embedding tables — the same latency is comfortably absorbed. The number itself is not good or bad; it is good or bad relative to your workload’s sensitivity.

Q: Which workloads should NOT use CXL memory?

Latency-sensitive, pointer-chasing workloads are the ones to keep on local DRAM and away from CXL pools. The clearest examples are online transaction processing (OLTP) databases, low-latency key-value stores, and latency-bound microservices whose performance is dominated by p99 response time rather than throughput. These workloads chase pointers through memory in dependent chains, so they cannot hide latency behind parallelism, and CXL’s added 70 to 200-plus nanoseconds per access — together with its worse and less predictable tail latency — lands directly on the metric they are judged by. No amount of favourable pooling economics compensates for a blown latency SLA. Two related anti-fits are worth naming. First, buying CXL simply to give one server “more RAM” and expecting the added memory to behave like fast local DRAM: expansion works, but the memory is slower, so a latency-bound workload is degraded, not helped. Second, deploying any pool without competent operating-system memory tiering: without hot/cold page placement that keeps the working set in local DRAM and demotes only cold pages to the pool, every access becomes a coin-flip between fast and slow memory. The right candidates are capacity- and bandwidth-bound workloads that tolerate a NUMA-hop of latency and run on a kernel that does tiering well.

Q: What is the current CXL specification, and is there a CXL 4.0?

The current released CXL specification is CXL 3.2, announced in December 2024, and there is no ratified CXL 4.0 — references to “CXL 4.0” in some roadmap blogs are speculative planning content, not an actual standard. The version history maps cleanly onto capabilities and onto the underlying PCIe generation. CXL 1.0 and 1.1 established the base coherent protocol over PCIe 5.0 (32 GT/s) and supported direct-attached memory expansion for a single host. CXL 2.0, still on PCIe 5.0, introduced memory pooling and single-level switching. CXL 3.0, in August 2022, moved to PCIe 6.0 (64 GT/s) — doubling the data rate with no added latency over 2.0 — and introduced memory sharing, multi-level switching and fabrics scaling to 4,096 endpoints. CXL 3.1 (November 2023) and CXL 3.2 (December 2024) extended the fabric, added Trusted Security Protocol features and improved device telemetry and manageability, all remaining backward compatible. For an architect the practical takeaway is that the generation you actually have in your silicon and modules determines whether you can only expand, can pool, or can share — and most shipping 2026 hardware supports 2.0-class pooling, which is what the majority of stranding problems require.

Q: Does CXL memory pooling actually save money, and how much?

It can save a meaningful amount, but the return depends heavily on scale and on the pool being sized correctly. Microsoft’s Pond study provides the most credible figures because it is measured against a real cloud fleet: pooling stranded DRAM reduces DRAM cost by about 7%, which flows through to roughly a 3.5% reduction in total server cost, while keeping application performance within 1 to 5% of a same-NUMA-node baseline across 158 workloads. Crucially, the savings do not scale linearly with pool size — Pond found that pooling across 8 to 16 sockets captures most of the available benefit, and a much larger 32-socket pool only reaches about 12% DRAM savings while adding switch latency and cost. That means the economics are strongest for large operators who can amortise switch capital across many servers and who genuinely have Azure-like stranding to reclaim; at the scale of a single rack, the fixed cost of CXL switches may not clear the value of the DRAM saved. The honest way to evaluate it is to first measure your own stranding — the gap between DRAM rented and DRAM touched — and only pursue pooling if you see numbers in the same range, then model switch capital, the added-hop latency, and operational complexity against the DRAM you would stop buying.

Q: What operating-system support does CXL tiered memory require?

CXL tiered memory depends on the operating system performing competent hot/cold page placement, and without it a pool underperforms badly enough to negate the economics. The core job is tiering: keeping frequently accessed “hot” pages in fast local DRAM while demoting rarely touched “cold” pages to the slower CXL tier, and promoting pages back when access patterns change. If the OS does this well, applications see close to local-DRAM performance for their working set while the bulk cold data lives cheaply in the pool; if it does not, accesses are distributed blindly and every memory reference becomes a gamble between fast and slow tiers. Linux support for this is real but relatively recent, which is why software maturity is a genuine precondition rather than a footnote. Meta’s Transparent Page Placement (TPP), designed specifically for CXL-enabled tiered memory, performs OS-level hot/cold placement that gets within about 1% of an all-local baseline, roughly 18% better than stock Linux NUMA balancing, and most of its patches were merged into the Linux kernel around version 5.18. Other mechanisms such as NUMA balancing and weighted interleave complement it. The practical implication is that any CXL pilot must validate, under real load, that the kernel actually demotes cold pages and promotes hot ones — proving the tiering works is a gate that comes before trusting the capacity savings.