CXL 4.0: a faster link does not make all memory local.

The specification changes the opportunity

The CXL Consortium announced specification 4.0 on 18 November 2025, with a 128 GT/s rate and features including bundled ports. The specification is a definition for implementations; its release does not mean every processor, switch, operating system or memory device immediately supports the new capability.

A deployment study should begin with an inventory of supported versions, topology and firmware, followed by the software path that exposes memory to the application. Compatibility needs to be established across the entire chain. A fast component attached through an older or differently configured path cannot be assumed to deliver the headline behaviour of the latest specification.

Sources: [1] CXL Consortium: specification 4.0 announcement, 18 November 2025

Transfer rate is not application bandwidth

GT/s describes transfers per second at the link, not gigabytes delivered to an application. Converting between them requires lane count, encoding, protocol overhead, direction and the actual transaction pattern. A specification-level rate therefore belongs in a link budget; application throughput belongs in a workload measurement.

We would also distinguish sustained throughput from latency. A pipeline can move large amounts of data while individual requests still experience a delay important to a service. Increasing link rate reduces one contribution to the data path, but does not remove routing, switching, device, coherence or software costs. The comparison should show where each portion of the delay originates.

Locality decides whether a tier helps

An application with a small hot working set and a much larger cold dataset may benefit from careful placement across memory tiers. An application that repeatedly touches its whole dataset with strict latency requirements may behave differently. Capacity alone does not describe those patterns, so the placement strategy should be tested rather than inferred from total allocated bytes.

A simple illustrative latency model is L_average = p L_local + (1-p) L_remote, where p is the fraction of accesses served locally. Suppose local and remote service times are 100 ns and 300 ns. With p = 0.9 the average is 120 ns; with p = 0.5 it is 200 ns. These invented values show sensitivity to locality, not the latency of a specific CXL product.

The average hides service risk

An average cannot describe queuing during contention or infrequent delays that dominate a service-level objective. We would measure median, high-percentile and worst-observed response times under controlled load, while identifying the sample count and test duration. A lightly loaded benchmark can miss the interaction between bandwidth pressure and tail latency.

Testing should include competing tasks, memory-pressure transitions and recovery from congestion. The application's own completion metric remains important: a database, simulation and media service may respond differently to the same memory path. A tier is useful when its predictable behaviour fits the workload, not when it merely adds an impressive amount of addressable capacity.

Shared resources require explicit fault boundaries

Expansion and pooling introduce questions about allocation, isolation and recovery. What happens when a device becomes unavailable, a link degrades or a tenant exhausts its allocation? The answer must be established in the chosen hardware and software stack. A protocol capability does not automatically implement an operator's availability or security policy.

We would require observable health, a clear ownership model and a documented degradation path before deploying a service. Fault injection should occur in an isolated test environment, not in a live customer system. The resulting evidence needs to distinguish recovered data, restarted work and lost progress, because those outcomes have different operational meanings.

Sources: [2] CXL Consortium: current specifications

COTT assessment

CXL is most interesting as a way to design memory around actual workload distributions and infrastructure constraints. The opportunity lies in reducing stranded capacity or accommodating larger working sets while retaining control over the hot path. It is not a reason to stop measuring latency, locality or failure behaviour.

Our preferred sequence is workload profiling, an explicit tiering policy, a representative pilot and application-level acceptance. Procurement should follow that evidence rather than precede it. This review does not claim a COTT CXL product, a deployed pooled-memory service or universal equivalence between expanded and local memory.