Researchers have shown that Linux systems can be engineered to rely heavily on remote memory pulled over a network, but the resulting performance penalty is severe enough to make such setups impractical for everyday use. Two academic papers published on the arXiv preprint platform examine disaggregated and remote memory architectures and quantify how badly latency can degrade performance when memory access has to travel across a network. The findings offer a clear answer to a question that hardware enthusiasts have long debated: yes, a machine can boot and run without local RAM, but the experience is predictably awful.
What Disaggregated Memory Actually Means
Traditional PCs rely on DRAM sticks physically seated on the motherboard, providing nanosecond-level access times that keep applications responsive. Disaggregated memory flips that model by placing RAM on separate networked nodes, letting a host machine request pages over a fabric link instead of reading them from a local bus. The concept has gained traction in data-center design, where pooling memory across racks can improve utilization rates and reduce hardware costs. But the trade-off is stark: every memory fetch that once took a few dozen nanoseconds now has to cross network hops, and the physics of that round trip cannot be fully hidden by software.
A research team explored this architecture by modifying the Linux kernel to treat remote servers as a memory tier, effectively allowing a system to disaggregate memory and computation across nodes, with remote memory acting as an additional tier rather than a direct substitute for local DRAM in typical PCs. Their work suggests that once memory accesses leave the local chip, latency can dominate execution time and overall performance can drop sharply. The system still ran. Applications still loaded. In the authors’ evaluation, throughput dropped enough that the system could resemble a machine leaning heavily on swapping rather than one backed primarily by local RAM.
Latency Penalties That Software Cannot Fully Fix
A separate line of research tackled the obvious follow-up question: if remote memory is slow, can smarter software make it tolerable? The answer, based on work integrating a prefetching system called Leap directly into the Linux kernel, is a qualified yes with a hard ceiling. The Leap project achieved notable latency reductions for remote page accesses by predicting which memory pages a process would need next and fetching them before the CPU stalled. Kernel-path optimizations cut the effective wait time for many workloads, but they could not eliminate the penalty entirely.
The core problem is physical distance. Even on a fast network, a round trip to a remote memory server takes orders of magnitude longer than a local DRAM read. Prefetching helps when access patterns are predictable, such as sequential scans through a database or linear reads of a file. It struggles with random or irregular access patterns, which are common in interactive desktop applications, web browsers, and games. In those cases, the CPU spends most of its time waiting for data rather than processing it, and no amount of clever prediction can fully compensate.
How Remote Memory Compares to Swapping
One of the more telling findings from the disaggregation research is how remote memory stacks up against standard network swap, the fallback mechanism Linux already uses when local RAM runs out. In a typical swap scenario, the kernel writes least-recently-used pages to a storage device and reads them back when needed. Network swap does the same thing but targets a remote server instead of a local SSD or hard drive. The academic work comparing these approaches argues that disaggregated remote memory and network swap are both constrained by the same fundamental bottleneck: network latency. In the reported results, the performance gap between the two can be narrower than expected in some cases, because both paths are constrained by the same network round trip.
This comparison matters because it challenges a common assumption in cloud computing circles. Proponents of memory disaggregation often argue that purpose-built remote memory protocols will vastly outperform crude swap-over-network setups. The research suggests the gains are real but bounded. Kernel integration and smart prefetching narrow the gap, yet neither approach can replicate the speed of having DRAM physically attached to the processor. For workloads that tolerate some latency, such as batch analytics or offline rendering, disaggregated memory can be a useful resource-sharing tool. For latency-sensitive tasks, it remains a poor substitute.
Why Local RAM Still Wins for Everyday Users
The practical takeaway for anyone building or upgrading a PC is straightforward: local DRAM is not going away anytime soon. The entire value proposition of disaggregated memory rests on scenarios where hardware utilization and cost efficiency matter more than raw speed, such as hyperscale data centers running thousands of virtual machines. In that context, letting idle memory on one server feed a hungry workload on another server makes economic sense, even if individual page accesses are slower.
Desktop and laptop users operate under different constraints. A web browser with dozens of tabs, a video editor scrubbing through 4K footage, or a game loading texture assets all generate memory access patterns that are bursty, unpredictable, and deeply sensitive to latency. Shifting those accesses to a remote node would turn a snappy machine into one that feels perpetually frozen. The research confirms what system architects have long understood: memory speed is not just about bandwidth but about latency, and latency is governed by proximity.
The Limits of AI-Driven Prefetching
One area that deserves scrutiny is the assumption that machine-learning-driven prefetchers could eventually close the gap. The Leap project’s kernel integration showed that even well-tuned prediction algorithms hit a wall when access patterns become irregular. In theory, adding more complex (including ML-based) predictors could improve hit rates for some workloads, but it would also add computational overhead and introduce new failure modes when predictions miss. There is no free lunch: every cycle spent predicting the next memory access is a cycle not spent doing useful work, and the payoff diminishes as patterns grow more chaotic.
The broader coverage of disaggregated memory tends to emphasize the upside, framing it as a path toward ultra-flexible cloud infrastructure. That framing is not wrong, but it glosses over the hard physics. Light travels about 30 centimeters per nanosecond. A memory server sitting even a few meters away introduces latencies that can dwarf the access times of local DRAM. Even with advanced fabrics and protocol optimizations, the time it takes for a signal to leave the CPU, traverse switches, reach a remote DIMM, and return cannot be shrunk to the scale of an on-motherboard trace.
In practice, this means that AI-driven prefetching can smooth out some of the worst stalls but cannot transform remote memory into a drop-in replacement for local RAM. When workloads follow regular patterns, prediction works well and the illusion of fast memory holds. When they do not, the system reverts to its true nature: a computer running entirely over a network, constrained by the speed of light and the overhead of every hop along the way.
Where Remote Memory Still Makes Sense
None of this renders disaggregated memory useless. In controlled environments where workloads are known in advance and can be tuned, remote RAM can help operators right-size servers and reduce stranded capacity. Batch processing, large in-memory analytics jobs, and certain high-throughput services can be scheduled with awareness of the latency hit, trading interactive responsiveness for better overall utilization. For those cases, the ability to allocate memory from a shared pool on demand is a powerful tool.
These experiments underscore both the promise and the limits of this approach. They prove that an operating system can be adapted to treat remote servers as its primary memory store, and that clever kernel engineering can keep such a system usable for narrow classes of tasks. They also make clear that for general-purpose computing, especially on consumer hardware, the gulf between local and remote memory remains too wide to bridge. Until someone finds a way around the laws of physics, the fastest RAM will be the chips sitting closest to the CPU.
More from Morning Overview
*This article was researched with the help of AI, with human editors creating the final content.
