Compute Express Link (CXL) is the most consequential data-center interconnect to emerge in years — and the reason "memory disaggregation" appears in nearly every AI-infrastructure discussion today. Day 1 explains the problem it solves, what makes it fundamentally different from PCIe, and the vocabulary you'll need for the rest of the course.
Modern servers suffer from two distinct, expensive memory problems at the same time:
The stranding problem is bigger than most people expect. Published data-center studies find that when about 75% of CPU cores are scheduled to VMs, an average of ~6% of total memory is stranded — installed but unreachable — and that figure rises to as much as 25% as VM and container density climbs. In a large fleet, that's an enormous amount of DRAM being paid for and delivering nothing.
Stranded-memory figures per published data-center memory-utilization research.
Both problems share the same underlying cause. In a conventional server, DRAM lives in DIMM slots wired directly to a specific CPU socket. That memory is captive — it can only ever serve the cores on that one socket. A neighboring socket that's desperate for more memory cannot borrow it; a socket whose cores are all busy cannot lend its idle memory out. Memory capacity is a fixed, non-transferable quantity bolted to each CPU.
CXL's core idea is to break that rigidity: make memory a shared, coherent resource reachable over a link, instead of a fixed amount hard-wired to one processor.
CXL (Compute Express Link) is an open, cache-coherent interconnect standard that runs on top of the PCIe physical layer. Two parts of that sentence matter enormously:
Plain PCIe moves blocks of data between a host and a device, but the two sides have no shared, hardware-maintained understanding of memory state. If a CPU and a PCIe device both have copies of the same data, keeping them consistent is entirely the software's problem — usually solved by expensive explicit copies and flushes.
Cache coherence changes this: the hardware itself tracks who holds a copy of each piece of memory and ensures everyone sees a consistent value. When one side modifies shared data, the coherence protocol makes sure the other side won't read a stale copy. This is exactly the guarantee that lets memory attached to a device behave, to software running on the CPU, almost like the CPU's own local DRAM — no manual copying, no explicit synchronization, just normal memory loads and stores.
The one-sentence summary: PCIe lets a device and a host exchange data; CXL lets them coherently share memory. That difference — coherence — is what turns an I/O bus into a memory fabric.
CXL isn't one protocol but three, multiplexed over the same link. Which ones a device uses defines what it can do:
| Sub-Protocol | Direction | What It Does |
|---|---|---|
CXL.io | Both | Configuration, discovery, enumeration, register access, DMA — functionally similar to PCIe. Every CXL device must support it; it's the mandatory baseline. |
CXL.cache | Device caches host memory | Lets an accelerator coherently cache the host's memory, so it can operate on shared data without constant round-trips back to the CPU. |
CXL.mem | Host accesses device memory | Lets the CPU read and write memory physically attached to a device — the foundation of memory expanders, pooling, and disaggregation. |
You'll spend all of Day 3 on these three in detail. For now, the key intuition: CXL.cache is about a device reaching into host memory, while CXL.mem is about the host reaching into device memory — opposite directions, different use cases.
Combine the sub-protocols in different ways and you get the three CXL device types — the classification you'll see constantly in any CXL discussion:
| Type | Sub-Protocols | Example |
|---|---|---|
| Type 1 | CXL.io + CXL.cache | An accelerator or SmartNIC with a cache but no host-attached memory of its own |
| Type 2 | CXL.io + CXL.cache + CXL.mem | An accelerator (e.g. GPU) with its own directly-attached memory that stays coherent with the host |
| Type 3 | CXL.io + CXL.mem | A memory expander — presents DRAM or persistent memory to the CPU. The workhorse of memory expansion and pooling. |
Notice Type 3 deliberately omits CXL.cache: a pure memory expander has nothing to cache from the host — its whole job is to be memory the host reaches into via CXL.mem. This is the device type most CXL memory-pooling and disaggregation deployments are built around.
Because CXL uses the PCIe physical layer, each CXL generation advances in lockstep with a PCIe generation. This is a preview of Day 2, but worth seeing now:
| CXL Version | PCIe Base | Signaling Rate |
|---|---|---|
| CXL 1.1 / 2.0 | PCIe 5.0 | 32 GT/s |
| CXL 3.0 / 3.1 | PCIe 6.0 | 64 GT/s (PAM4) |
| CXL 4.0 (Nov 2025) | PCIe 7.0 | 128 GT/s |
Reusing PCIe's physical layer was a deliberate strategic choice: it let CXL inherit a mature, high-volume electrical ecosystem instead of inventing a new one, which is a large part of why CXL went from specification to real silicon so quickly.