Memory pooling is usually drawn as a clean fan-out diagram: servers on one side, capacity devices on the other, and a switch in the middle. The diagram hides the procurement problem. A switch that can reach every endpoint adds ports, SerDes, retimers, power and another serialization hop. A switchless design avoids that bill, but a four-port memory device cannot connect to dozens of servers at once. Octopus asks whether full connectivity is the wrong requirement in the first place.[1]
This is a top-tier systems paper with an unusually physical thesis. The topology must fit inside three racks, every passive copper cable must remain below 1.5 m, and a server has only eight CXL ports. The authors combine Microsoft Azure traces, measured multi-ported CXL hardware and graph constructions to design a 96-server pod. Their conclusion is not that sparse wiring is free. It is that a carefully chosen sparse graph can preserve the two connections that matter: enough shared devices for pooling, and at least one common device for servers that need fast communication.
Two incompatible jobs inside a memory pod
Pooling and communication reward opposite kinds of overlap. Memory pooling benefits when the busiest servers reach different memory-pooling devices (MPDs). Their demand peaks then spread across more capacity, so no single device must be provisioned for the sum of several hot hosts. Low-latency communication wants the reverse. If two servers share an MPD, one can place a buffer there and the other can read it without a network stack or a CXL switch.
A fully connected MPD pod maximizes overlap, but low port counts bound its size. With four-port MPDs and eight links per server, combinatorial designs that guarantee a shared device for every server pair top out at 25 servers. A generic expander graph can scale to 96 servers and distribute demand well, but it does not guarantee that an arbitrary pair shares a device. Messages between unconnected pairs must be forwarded through multiple MPDs, and the paper measures the cost: a 64-byte RPC rises from 1.2 µs through one MPD to 3.8 µs through two. At that point the path is comparable to in-rack RDMA.
Octopus resolves the conflict by admitting that not every pair needs the same latency. It divides the pod into islands. Inside each island, a subset of each server’s eight ports connects to island-specific MPDs and guarantees pairwise overlap. The remaining ports reach external MPDs that connect the islands and improve graph expansion. This is a workload statement encoded in cables: communication locality is strong within an island, while pooling remains pod-wide.
The 96-server construction
The default design has six islands of 16 servers, 96 servers in total and 192 four-port MPDs. Each server uses eight CXL ports. The center rack holds the MPDs, while the two adjacent racks hold servers. Under the paper’s placement model, the known-minimum cable length is 1.3 m, within the 1.5 m passive-copper constraint. The number is important because a graph that works on paper but requires optical CXL or active copper has a different cost and failure model.
The design method first determines how many island ports are needed to guarantee pairwise overlap, then uses the remaining ports to construct an expander across islands. In graph terms, overlap creates short communication paths, while expansion lower-bounds how many distinct MPDs any hot subset can reach. The allocator places a new virtual machine on the least utilized connected MPDs and may stripe its memory across several devices. Pooling quality is then determined by peak usage per MPD rather than average utilization across the pod.
This is also where the result differs from a universal fabric. A server cannot reach every byte in every MPD. Octopus exposes a constrained placement problem to the control plane. A VM with a large memory allocation must fit across the devices its host can reach, and migration or failure recovery must respect the same reachability. The topology saves switch cost by spending more intelligence in placement.
What the hardware actually validates
The prototype has three servers and three multi-ported devices, not 96 servers. It measures device latency, bandwidth, communication and application sensitivity, then feeds those values into the scaled simulation. The MPD load-to-use latency is 267 ns, compared with 233 ns for a direct expansion device. On one link, a read-only stream reaches 24.7 GiB/s and a write-only stream reaches 22.5 GiB/s. When both connected servers issue traffic, each reaches a 22.1 GiB/s ceiling; the authors attribute weaker mixed read-write scaling to prototype firmware.
For 64-byte RPCs within an island, the median round trip is 1.2 µs. A measured CXL-switch path is 2.4 times slower, and RDMA reaches 3.8 µs, 3.2 times slower. Large-message pointer passing avoids copying the payload through a network path. A three-server ring all-gather with 32 GiB per server finishes in 2.9 s; its combined two-direction rate is 22.1 GiB/s and is again limited by the MPD firmware. These results establish the mechanism, but they do not demonstrate 96-way contention.
Application sensitivity matters more than an isolated latency ratio. Across web, key-value, database and analytics workloads, about 65% incur less than 10% slowdown on the MPD configuration. The authors would not place highly latency-sensitive workloads on pooled memory. That qualification is central: pooling savings depend on how much capacity the provider is allowed to move out of local DRAM after applying a slowdown threshold.[2][4]
The economic result is conditional, not decorative
Trace-driven simulations compare Octopus, switch-based pods and other MPD graphs. At 96 servers, Octopus saves about 16% of memory capacity relative to no pooling, close to larger expander graphs that violate the cable constraint. The benefit flattens near 100 servers because demand aggregation has already reduced much of the peak-to-average gap.
After device and cable costs are included, Octopus reduces total server capital cost by 3.0% when the baseline has no CXL expansion. If CXL expansion is already present, the reduction is 5.4%, because a multi-ported device costs only modestly more than the expander that it replaces. The modeled switch topology increases cost in both cases; even with an expansion baseline it adds 0.6%.
Those percentages should not be transferred to another fleet without rebuilding the model. DRAM’s share of server cost, the local-memory performance threshold, MPD pricing, cable cost, failure reserve and demand correlation all affect the sign of the result. The earlier case against small CXL pools argued that switch and stranded-capacity costs can exceed the benefit.[3] Octopus answers by changing the topology and scale, not by disproving the economic concern.
What can break the design
First, random pod-wide communication is the weak case. With only 10% of servers active, Octopus is 12% below an expander topology under random traffic because islands reserve links for local overlap. A workload whose peers change unpredictably should not be mapped as if island locality were stable.
Second, failures remove reachability as well as bandwidth. The paper simulates random CXL link failures and shows declining pooling savings because hosts lose access to some MPDs. Real operation would need spare capacity, route-aware admission and a repair procedure that can evacuate data before a degraded island exhausts its remaining devices.
Third, the cost model assumes today’s low-port-count MPDs and passive copper. Eight-port devices, optical links or a cheaper switch would move the optimum. Octopus is best understood as a method for choosing topology under physical constraints, not a permanent answer for every CXL generation.[5]
A practical acceptance test
An operator should test three layers separately. The hardware layer measures single-link read, write and mixed bandwidth, tail latency, hot-plug behavior and error containment on the intended cable length. The topology layer replays the provider’s memory traces against the exact reachability graph and includes failed links, maintenance drains and correlated demand. The service layer places communication-heavy jobs both within and across islands, then verifies that the scheduler knows the difference.
The key purchasing question is therefore not “How many hosts can this pool connect?” It is “Which host pairs can share a low-latency device, how much independent capacity can any hot subset reach, and what does the allocator do when either property is violated?” Octopus earns its value only when those three answers remain aligned.
Source and attribution
This article is an editorial analysis prepared by Silicon & Systems. The paper’s arguments and reported measurements are restated in our own words. No paper text, table or figure is reproduced; both figures were created for this article. The original paper and presentation are available from USENIX NSDI 2026. Copyright is retained by the authors, (c) 2026.