Phase 1 taught you the concepts. Phase 2 walked the spec versions in order. Phase 3 asks the question that actually matters to the people paying for data centers: does any of this get deployed, and does it work? Day 11 opens Phase 3 with the deployment that's furthest along — memory pooling — and the real, measured 2025–2026 results behind it.
Day 1 introduced stranded memory in the abstract: DRAM that's physically present but unusable because some other resource in the server ran out first — CPU cores, power budget, or PCIe lanes. The commonly cited industry figures are around 6% average stranded memory fleet-wide, spiking as high as 25% at peak. Ten years ago that was an annoyance. In 2026, it's a line item that gets executive attention, for a specific reason: DDR5 server memory costs roughly $30–40 per GB, and AI workloads are doubling their memory needs roughly every 18 months. Simple DIMM-based scaling — just buy more memory per server — is becoming an expensive way to solve a problem that pooling solves for a fraction of the cost, because pooled memory doesn't need to be stranded in the first place.
The blunt version: if 15–25% of a fleet's DRAM sits idle behind some other bottleneck, and DRAM costs $30–40/GB, that's tens of millions of dollars of hardware doing nothing at hyperscale. Pooling doesn't add capacity — it makes the capacity you already bought actually reachable by whichever server needs it right now.
Put concrete numbers on it: a fleet running 10,000 servers with 512GB of DRAM each holds 5.12 petabytes of installed memory. Even the conservative 6% average stranding figure means roughly 307 terabytes sit unreachable at any given moment — at $30-40/GB, that's $9-12 million of hardware doing nothing, continuously, not as a one-time write-off. Pooling doesn't have to reclaim all of that to be worth building; reclaiming even a third of it already pays for a modest CXL switch and pool-appliance rollout many times over.
Mechanically, a CXL memory pool is the direct, physical realization of Day 7's switch-and-MLD architecture and Day 8's Global Fabric Attached Memory (GFAM), assembled into a real piece of data-center hardware: a pool appliance. Concretely, that's typically a chassis packed with DRAM across multiple Type 3 memory expander modules, connected through a CXL switch to a rack's worth of host servers — sometimes described informally in the industry as "JBOM" (Just a Bunch Of Memory), echoing the older JBOD storage term.
The Fabric Manager's rebinding capability is the entire economic case in one sentence: instead of provisioning every server for its peak memory need (and eating the stranded-memory cost the rest of the time), a fleet provisions the pool for aggregate peak need, and lets the Fabric Manager hand capacity to whichever host is under memory pressure right now. A server whose workload just finished can release its allocation back to the pool within minutes, for another host to pick up — something a fixed DIMM configuration can never do.
Phase 2 (Days 6–10) was entirely about what the CXL specification defines. Phase 3 is about what's actually been measured, in real deployments, recently:
| Source / Date | Result |
|---|---|
| Microsoft Research, NSDI 2026 | Sparse CXL pod topologies achieved communication latency 3.2× lower than in-rack RDMA |
| Samsung, July 2026 | CXL memory maintained 92% of DRAM performance in 8-GPU configurations, at much larger capacity |
| H100 LLM inference benchmark | CXL memory pooling showed 3.8× speedup vs 200G RDMA and 6.5× speedup vs 100G RDMA (OPT-6.7B model, two-server setup) |
| XConn / MemVerge, SC25 (Nov 2025) | Scalable CXL memory solution to offload KV cache and prefill/decode disaggregation for AI inference workloads |
Results per Microsoft Research NSDI 2026, Samsung's July 2026 evaluation, and industry benchmark/announcement materials from late 2025 and 2026.
That Microsoft Research result is worth sitting with: a switched CXL pool beating in-rack RDMA — the fast path within a single rack — by 3.2× strengthens the economic case for pooling considerably, because it means pooling isn't just "acceptable" compared to the alternative, it's measurably better on the metric people actually care about. The Samsung figure (92% of DRAM performance) directly answers the honest-latency-cost question this course has returned to since Day 2: pooled CXL memory isn't free, but it's close enough to local DRAM that giving up the remaining 8% for dramatically larger, reassignable capacity is an easy trade for many workloads.
The XConn/MemVerge result points at exactly why pooling is being deployed now rather than staying a research curiosity: LLM inference has a memory problem that pooling is unusually well-suited to solve. Two specific mechanisms are driving this:
This is the practical, deployed cousin of the "memory wall" framing from Day 1: GPUs have enormous compute but comparatively limited local memory, and AI workloads are doubling their memory footprint roughly every 18 months (per the industry figures above). A GPU cluster that's compute-rich but memory-constrained is precisely the scenario where pooled CXL memory — reachable at near-DRAM latency per Samsung's numbers — lets you keep feeding the GPUs instead of leaving them idle waiting on memory.
It's worth being precise about which CXL capability is actually shipping in 2025–2026 deployments, because Day 8 drew an important distinction. Everything described above is pooling (CXL 2.0's model, Day 7): a region of memory is assigned to one host at a time, reassignable by the Fabric Manager. It is not yet full sharing (CXL 3.0's model, Day 8), where multiple hosts coherently touch the same region simultaneously via Back-Invalidate Snoop.
Why pooling wins the race to production: pooling only has to solve "which single host owns this memory right now" — a coordination problem the Fabric Manager can handle in software with a bind/unbind operation. Sharing has to solve "how do multiple independent hosts stay coherent on the same live data," which needs mature CXL 3.0/3.1 switch silicon and BISnp-capable memory devices that are still catching up to what the specification defines. Industry timelines reflect exactly this gap: memory tiering is targeted for 2025–2026, memory pooling deployment for 2026–2027 using CXL switches — and full multi-host sharing sits later still, gated on the switch and software maturity that Day 8's spec described but that took longer to reach production silicon.
None of the hardware above matters if the operating system can't use pooled memory sensibly. This is where CXL's software story turns out to reuse an idea Linux already had: NUMA (Non-Uniform Memory Access). Linux exposes CXL memory to software as a CPU-less NUMA node — a memory-only node with no cores attached, sitting one tier below local DRAM. On systems where the BIOS provides valid HMAT or CDAT tables (hardware tables describing memory latency/bandwidth characteristics) and the CXL driver stack is loaded, Linux's memory tiering framework configures itself automatically at boot: existing DRAM-backed NUMA nodes become the fast default tier, and the CXL node is placed into a slower tier based on its measured abstract distance — a number derived from the hardware's own latency/bandwidth reporting, not a guess.
The remaining problem is deciding which pages actually belong on the slower CXL tier. Linux solves this with DAMON (Data Access MONitor), configured with a DAMOS_MIGRATE_COLD scheme: DAMON proactively identifies cold pages — memory that hasn't been touched recently — and migrates them from fast DRAM down to CXL memory before memory pressure forces a worse decision. The reverse path exists too: if a page sitting in CXL memory suddenly gets accessed frequently by a CPU whose local DRAM tier is faster, the kernel promotes it back up. This closes the loop that makes pooling practically usable: applications don't need to be rewritten to know about CXL at all — the kernel handles hot/cold placement transparently, using exactly the tiered-NUMA machinery Linux already had for other multi-socket memory topologies.
The open engineering problem: getting tiering right requires continuously monitoring runtime signals — bandwidth utilization, read/write ratios, and the distribution of page-access frequency — because the right migration policy changes as those signals change. If a workload suddenly drives heavy bandwidth against the slow CXL tier, that's the moment more hot pages need to move back to fast DRAM, not fewer. This monitoring-and-policy problem, not the CXL hardware itself, is where much of the current software engineering effort in CXL memory tiering is actually concentrated.
Current state-of-the-art designs — described in industry materials under names like Octopus and OCP Tiered Expanders, alongside hybrid fabric cluster approaches — demonstrate practical pool sizes of tens to hundreds of hosts, with stepwise total-cost-of-ownership reductions at each scale step, and system-level performance that's genuinely competitive with local-attached DRAM rather than merely "good enough." This is a meaningfully different picture from CXL 3.0's theoretical GFAM ceiling of 4,096 nodes (Day 8) — real 2026 deployments are proving the concept works robustly in the tens-to-hundreds range first, which is exactly the scale most enterprise and hyperscale racks actually operate at, before anyone needs to push toward the architecture's theoretical maximum.
The reason this "prove it small, then scale" pattern matters is that TCO gains from pooling aren't linear with pool size — they follow a curve where the first step (going from zero pooling to a modest tens-of-hosts pool) captures a large fraction of the available stranded-memory reclaim, because most of that stranded capacity was scattered across ordinary, moderately-utilized servers rather than concentrated in a few extreme outliers. A rack operator doesn't need a 4,096-node GFAM deployment to see meaningful savings; a single switch connecting a few dozen hosts to one pool chassis already captures most of the win described at the start of this page. That's part of why pooling is the deployment that's furthest along across the whole CXL ecosystem — the return on a modest, well-understood first deployment is high enough that operators don't need to wait for the architecture's full theoretical scale to justify rolling it out.
It's worth being honest about the limitations, because they explain why pooling deployment is a multi-year rollout rather than a switch anyone flips overnight. First, pooled CXL memory is still a slower tier than local DRAM — Samsung's 92% figure is excellent, but it's not 100%, and a workload with no tiering awareness at all can regress if too much of its hot working set ends up parked on the CXL tier by an over-aggressive migration policy. Getting DAMON's cold/hot thresholds right for a given workload is real tuning work, not a solved, one-size-fits-all default.
Second, pooling introduces a genuinely new fault-domain question: a pool appliance is now a piece of shared infrastructure that multiple hosts depend on, where a single-host DIMM failure used to be an isolated, contained event. Data-center operators have to reason about the blast radius of a pool appliance failure differently than they reason about a single server's local memory failing — the reliability engineering isn't identical just because the latency numbers look similar to local DRAM.
Third, none of this eliminates the need for composable infrastructure thinking more broadly. Memory pooling is the most mature piece of a larger vision — sometimes called composable or disaggregated infrastructure — where compute, memory, and storage are provisioned as independently scalable resources rather than fixed per-server bundles. Pooling proves the memory piece works. The harder pieces (disaggregating compute itself, or building fully general composable racks) are still ahead, which is exactly why this course frames pooling as Phase 3's opening topic rather than its conclusion.
The honest summary for Day 11: CXL memory pooling is real, measured, and already beating alternatives like in-rack RDMA in independent benchmarks — this is not vaporware. But it's also not a free lunch: it needs a tuned software tiering stack, a rethink of fault domains, and workloads that tolerate a slower (if only slightly slower) memory tier for part of their footprint. The technology is ready; the operational maturity around it is still catching up, which is precisely why 2026-2027 is being described as the pooling deployment window rather than something already fully mature today.