pulse: Accelerating Distributed Pointer-Traversals on Disaggregated Memory

Big systems increasingly keep their memory in a shared pool across the network so any machine can use it, but reaching that remote memory is roughly ten times slower than local memory, and the usual fix — a local cache — is useless for the very common task of chasing pointers through linked structures like database indexes, because each step's address is only known after the previous fetch; this work from Yale builds pulse, which puts a small fast accelerator right next to the remote memory to do the pointer-chasing locally and reuses the network switch to hop between memory servers, cutting latency by up to 34 times and energy by about 5 times.

The argument in one glance

Problem

Remote memory is slow, and caches cannot help pointer-chasing

Disaggregated memory keeps a shared pool of DRAM on network-attached servers, but reaching it is about ten times slower than local memory. The usual fix, a cache at the CPU node, cannot help workloads that chase pointers through linked structures like database indexes, because each step's address is only revealed by the previous fetch, so it cannot be prefetched, and traversals touch scattered nodes the cache rarely holds.
What people did

Run the traversal on a processor near the memory

Since caching fails, put processing near the remote memory to do the pointer-chasing there. Prior work has tried this with full CPUs (via remote procedure calls), small in-order cores, or fixed-function accelerators wired for one data structure.
Why it fell short

Existing near-memory options force a bad three-way tradeoff

Full CPUs are expressive and fast but overkill and power-hungry for memory-bound traversals. Small cores are expressive but slow, wasting energy. Fixed accelerators are fast and efficient but only handle one hard-wired structure. And none handle traversals that span multiple memory servers, because deciding whether a step is local or remote needs complex state — so they confine data to a single server.
This paper's idea

One expressive traversal accelerator, routed by the switch (pulse)

pulse gives memory servers a lightweight, fast accelerator for pointer traversals. Developers express traversals through a single iterator abstraction that ports many linked structures. The accelerator decouples its compute pipeline from its memory pipeline and multiplexes many traversals to stay busy and save energy. And it treats a cross-server pointer as a routing decision, using a programmable network switch to hop between servers — cutting latency by up to 34 times and energy by about 5 times.

Why this problem is worth solving

Disaggregation is spreading, and its central weakness is the speed of reaching remote memory.

Traditionally each server has its own DRAM. Memory disaggregation breaks from that: it keeps much of the memory in a separate pool on network-attached memory servers, and gives each CPU node only a small amount of local DRAM, which it uses as a cache while drawing the bulk of its memory from the remote pool. This is attractive because memory can be allocated flexibly across the pool, giving high utilization and elasticity — no server is stuck with idle DRAM or starved for it. The catch is latency. Reaching memory across the network is far slower than reaching local memory, and no amount of faster networking fully fixes this, because the speed of light itself bounds how fast a signal crosses the rack. Even with fast interconnects, a remote access is roughly an order of magnitude slower than a local one — for example, around three hundred nanoseconds for the newer memory interconnects versus ten to twenty nanoseconds for a local last-level cache. Caching hot data at the CPU node reduces the average latency and the network traffic, but only when the workload has locality that fits the small cache. In many cases the remote accesses are simply unavoidable, and the cost of the network dominates performance.

The workloads that suffer most are exactly the ones caches cannot rescue.

A large class of important workloads spends its time on pointer traversals through linked data structures: walking a B-tree or other index in a database or key-value store, or following edges in a graph. A pointer traversal reads a node in memory, finds a pointer inside it, and follows that pointer to the next node, repeating until it arrives. Two properties make this pattern miserable on disaggregated memory. First, the accesses are dependent: the address of the next node is only revealed once the current node has been fetched, so the system cannot prefetch ahead — it must wait for each remote fetch before it even knows what to fetch next. A traversal of several levels therefore pays several full network round-trips back to back. Second, there is little reuse: different lookups walk different paths through the structure, touching scattered and ever-changing nodes, so the CPU node’s cache rarely holds the node a given traversal needs. Caching, which works by keeping reused data close, has nothing to grab onto. The paper measures that real cloud applications spend a large fraction of their time in such traversals, and that as data structures are spread finely across memory servers for balance, most requests must cross from one server to another — so the pointer-chasing is not only cache-unfriendly but distributed.

What people did before, and where it broke

Cache hot data at the CPU node. Keep frequently-used remote data in the CPU node’s small local DRAM. Where it broke. Pointer traversals have dependent accesses that cannot be prefetched and little reuse, so the cache rarely holds the next node; caching fundamentally cannot accelerate them.
Offload traversals to full CPUs on the memory servers (remote procedure calls). Put general-purpose processors near the memory and call them to do the work. Where it broke. These traversals are memory-bound, not compute-bound, so full CPUs are overkill and underutilized, wasting energy — the opposite of disaggregation’s efficiency goal.
Use small in-order cores, or fixed-function accelerators. Put lightweight processors, or hardware wired for one specific data structure, near memory. Where it broke. Small cores are too slow and waste static power (poor energy efficiency and a bottleneck at high memory bandwidth); fixed accelerators are fast and efficient but only handle the one structure they were built for, losing expressiveness. And none of these handle traversals spanning multiple memory servers, because deciding local-versus-remote needs complex address-translation state, so they confine each structure to one server.
The gap. No design gave memory servers a traversal accelerator that is at once expressive across many linked structures, energy-efficient and fast, and able to traverse across multiple servers. Providing all three is what pulse does.

How pulse works

From cache-missing remote traversals to near-memory, switch-routed ones

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Do the pointer-chasing where the data lives. The core waste is that each dependent step of a traversal crosses the slow network just to read the next node and learn where to go next. pulse’s first move is to place a lightweight, fast accelerator right beside the remote memory, so a traversal reads a node, computes its next pointer, and reads again all at memory speed, and only the final answer travels back across the network. Moving the computation to sit next to the data, so that work which would otherwise shuttle bytes back and forth happens locally, is the same principle the analytics-storage work covered elsewhere on this site is built on, pushing a query down to run where the data physically resides instead of hauling the data to the query.

Find one abstraction from which the accelerator and the distribution both follow. Supporting many linked structures without a full CPU seems to demand either giving up expressiveness or giving up efficiency. pulse escapes the bind with a single iterator abstraction that captures pointer traversals across B-trees, graphs, and more, and it is chosen so that a tractable hardware accelerator and an efficient distributed-traversal mechanism both fall out of its structure. Designing one clean abstraction so that the properties you want downstream emerge from it rather than being bolted on is the same move the time-indexed stream-query work covered elsewhere on this site makes, expressing queries in a form from which fusion and parallelism follow naturally.

Overlap compute and memory so a lean accelerator stays full. A single pointer traversal is inherently sequential — read, compute, read — so it spends most of its time waiting on memory, leaving compute idle. pulse decouples the compute pipeline from the memory pipeline and runs many traversals together, switching to another traversal’s computation whenever one stalls on a fetch, so a handful of logic units keeps the memory bandwidth saturated and wastes little energy. Hiding the latency of one operation by overlapping it with useful work from another is the same technique the secure-computation pipelining work covered elsewhere on this site uses, overlapping communication with computation so the waiting is filled rather than paid.

Following a B-tree lookup through pulse

Chasing a B-tree index in disaggregated memory

Tracing one lookup shows the near-memory accelerator and the switch working together.

Step 1 of 5

A lookup must walk a B-tree index

A key-value store does a lookup that walks a B-tree index living in the remote memory pool. Each step reads a tree node and follows a pointer to the next level down.

The index is far larger than the CPU node's small cache.

Why it works

Remote memory is far slower than local. Because disaggregated memory sits across the network, roughly an order of magnitude slower than local memory → every access pays that latency → so keeping traversal steps off the network matters more than raw compute speed.
Pointer chasing defeats caching. Because each step’s address is only revealed by the previous fetch, so it cannot be prefetched, and traversals touch scattered nodes → the CPU cache rarely holds what is needed → so caching alone cannot speed these workloads.
Compute near the data avoids the round-trips. Because a lightweight accelerator beside the memory reads a node and follows its pointer locally → the many dependent hops happen at memory speed, not network speed → so only the final result crosses the network.
Decoupling and multiplexing keep a lean accelerator busy. Because a single traversal is sequential and spends most of its time waiting on memory → running many traversals and switching to another’s compute during a stall → so a few logic units saturate abundant memory bandwidth and waste little energy.
The switch already knows how to route. Because a cross-server pointer is essentially a routing decision, and a programmable switch already inspects packets to route them → letting it read the next pointer and forward the request → so distributed traversals flow server-to-server without returning to the CPU.

What it costs (trade-offs and scope)

It needs new hardware in the memory servers and the network. pulse adds a traversal accelerator beside each memory server and uses a programmable network switch. The paper prototypes the accelerator on an FPGA and reports the changes are not invasive, but this is a hardware deployment, not a software update.
Developers must express traversals in the iterator model. The benefits come through pulse’s iterator abstraction and its scratchpad for state; porting a data structure is designed to be low-effort, but it is a porting step, and a traversal that does not fit the iterator shape falls outside the model.
State per traversal is bounded. The scratchpad for intermediate state is a pre-configured size, so traversals needing large or unbounded working state may not fit, which bounds the expressiveness the abstraction can offer.
The gain depends on the workload being traversal-heavy and cache-unfriendly. pulse targets pointer-chasing that caching cannot help. Workloads with strong locality that the CPU cache already serves, or that are compute-bound rather than memory-bound, have less to gain.
The distributed win assumes a programmable switch topology. Routing cross-server hops at the switch fits a rack-scale disaggregated deployment with a programmable switch in the path; settings without such a switch, or at larger scale, would need rethinking.
It is a targeted accelerator, not a general processor. pulse deliberately does one thing — pointer traversals over its iterator abstraction — efficiently. General near-memory computation beyond that pattern is out of its scope by design.

The evaluation

Three ways to handle pointer traversals on disaggregated memory

Property	CPU-node caching	Near-memory CPUs (via RPC)
Helps pointer traversals		Yes
Expressive across many structures	Not applicable
Energy efficient	Not applicable
Traverses across memory servers	Not applicable
Result	Baseline	Fast but power-hungry

Three ways to run pointer traversals on rack-scale disaggregated memory, evaluated with a real prototype (an FPGA-based accelerator and a programmable network switch) on real workloads including the WiredTiger and BTrDB storage engines. Caching at the CPU node cannot help pointer-chasing, whose dependent, low-reuse accesses miss the cache. Offloading to full CPUs on the memory servers works but is overkill for these memory-bound workloads, wasting energy, and struggles to traverse across servers because deciding local-versus-remote needs complex state. pulse gives memory servers a lightweight traversal accelerator driven by a single iterator abstraction, decouples its compute and memory pipelines and multiplexes many traversals to stay efficient, and routes cross-server hops through the programmable switch by treating a remote pointer as a routing decision. Against disaggregated caching systems pulse achieves 9 to 34 times lower latency and 28 to 171 times higher throughput, and against remote-procedure-call schemes it uses 4.5 to 5 times less energy.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

pulse is a clean systems-and-architecture contribution that identifies a specific, important weakness — pointer traversals are both the workload caching helps least and a growing share of real applications on disaggregated memory — and attacks it with three well-matched ideas. It places a lightweight accelerator next to the memory so the dependent hops of a traversal happen locally instead of each crossing the slow network; it drives that accelerator with a single iterator abstraction chosen so that both a tractable hardware design and an efficient distributed mechanism follow from it; and it recognizes that a cross-server pointer is really a routing decision, so it reuses a programmable network switch to hop between memory servers without bouncing back to the CPU. The accelerator further decouples compute from memory and multiplexes many traversals, so a few lean logic units keep the memory bandwidth full and save energy. The measured results are strong and come from a real prototype: up to 34 times lower latency and 171 times higher throughput than disaggregated caching, and about 5 times less energy than offloading to CPUs. Read it with its scope. pulse is new hardware in the memory servers and the network, not a software change; developers must express traversals in its iterator model with a bounded scratchpad for state; the gains depend on the workload being traversal-heavy and cache-unfriendly; and the distributed routing assumes a rack-scale programmable-switch topology. The durable idea is that as memory moves across the network, the traversals that caching cannot help are best served by moving a small amount of the right computation to the data, and by noticing that following a pointer across servers is the same problem the network already solves.

Background

Why moving compute to data keeps winning as memory disaggregates

It helps to see pulse within a broad shift: as systems pull memory, storage, and compute apart across a network, the cost of moving data between them comes to dominate, and the winning response is repeatedly to move a little of the right computation to where the data lives rather than hauling the data to the computation. pulse does this for pointer traversals, running them beside the remote memory. The userspace-storage-access work covered elsewhere on this site makes a kindred move for storage, reusing existing hardware to build a direct path so data does not detour through the host — and, like pulse, it wins by repurposing a piece of infrastructure that was already there for a neighboring job. The common thread is twofold: first, in a disaggregated world, latency and energy are spent mostly on data movement, so eliminating a round-trip is worth more than speeding up a computation; second, the cheapest way to do the near-data work is often to lean on hardware that already exists — a switch that already routes, an interface that already translates — rather than to build something wholly new. As disaggregation deepens, the systems that thrive will be the ones that place computation thoughtfully across the pulled-apart components and that recognize when a problem they face is one the surrounding infrastructure already knows how to solve.

If you remember only three things

1. Disaggregated memory keeps a shared DRAM pool on network-attached servers for high utilization, but remote access is about an order of magnitude slower than local. Caching at the CPU node hides some of this, but it fundamentally cannot help pointer traversals through linked structures (database B-tree indexes, graphs): each step's address is revealed only by the previous fetch, so accesses are dependent and cannot be prefetched, and different traversals touch scattered nodes, so the cache rarely holds the needed node. These traversals are common, and as structures spread finely across servers, most requests must cross from one memory server to another.
2. pulse accelerates these traversals near the memory with three ideas. A single iterator abstraction (with a bounded scratchpad for state) lets developers port many linked structures and lets one accelerator serve them all. The accelerator decouples its compute pipeline from its memory pipeline and multiplexes many concurrent traversals, so while one waits on memory another computes — letting a few lean logic units saturate the memory bandwidth and save energy. And it treats a pointer that crosses to another memory server as a routing decision, reusing a programmable network switch to inspect the next pointer and forward the request server-to-server, so distributed traversals never bounce back to the CPU.
3. On a real prototype (an FPGA accelerator plus a programmable switch) with workloads like the WiredTiger and BTrDB storage engines, pulse achieves 9 to 34 times lower latency and 28 to 171 times higher throughput than disaggregated caching systems, and uses 4.5 to 5 times less energy than offloading traversals to CPUs. Its scope: it is new hardware in the memory servers and network rather than a software change, developers must use its iterator model with a bounded state scratchpad, the gains require traversal-heavy cache-unfriendly workloads, and the distributed routing assumes a rack-scale programmable-switch topology.

Check yourself

Check your understanding

1. Why can a cache at the CPU node not help pointer traversals on disaggregated memory?
2. What is the core idea behind pulse's accelerator placement?
3. How does pulse handle a traversal that must cross from one memory server to another?
4. pulse's accelerator decouples its compute pipeline from its memory pipeline and multiplexes many traversals. Why?

Sources

The paper is “pulse: Accelerating Distributed Pointer-Traversals on Disaggregated Memory” by Yupeng Tang, Seung-seob Lee, Abhishek Bhattacharjee, and Anurag Khandelwal, published at ASPLOS 2025, DOI 10.1145/3669940.3707253. The authors are at Yale University.

This explainer is written from the full text of the paper, obtained from the authors’ arXiv preprint (2305.02388, the extended version), which matches the ASPLOS 2025 proceedings. Everything above comes from the paper’s own sections: the introduction and motivation on memory disaggregation and the latency of network-attached memory (with the figures of roughly three hundred nanoseconds for newer interconnects versus ten to twenty nanoseconds for a local last-level cache) and why caching cannot help pointer traversals of linked data structures (dependent, non-prefetchable accesses with little reuse, common in database and key-value index lookups and graph analytics, and increasingly distributed across memory servers as structures are finely allocated); the analysis of prior near-memory and processing-in-memory approaches and their three-way tradeoff between expressiveness, energy efficiency, and performance, and their inability to support distributed traversals due to complex address-translation state; and pulse’s three design elements — its iterator-based programming model with a bounded scratchpad for stateful traversals, its accelerator that decouples the logic and memory pipelines and uses a scheduler to multiplex concurrent traversals for high utilization and energy efficiency (prototyped on an FPGA), and its in-network distributed traversal that treats a cross-server pointer as a routing decision handled by a programmable switch — together with the evaluation on a real-system prototype with workloads including WiredTiger and BTrDB, reporting 9 to 34 times lower latency and 28 to 171 times higher throughput than disaggregated caching systems and 4.5 to 5 times less energy than remote-procedure-call schemes.