DMG: A Scalable and Efficient Memory-Disaggregated Graph Processing System

Unknown

Conceptio › Archive › arXiv CS

arXiv CSopen access

DMG: A Scalable and Efficient Memory-Disaggregated Graph Processing System

Unknown · 2026 · arxiv_cs

arXiv CS · Papers · License: Open Access · 2026

Open Source ↗Direct PDF ↓

cloud distributedcomputing parallelcomputing

distributed computing, parallel computing, cloud

DMG: A Scalable and Efficient Memory-Disaggregated Graph Processing System Yizou Chen

The Chinese University of Hong Kong [email protected]

Tsun-Yu Yang

Duke University [email protected]

Baotong Lu

Microsoft Research [email protected]

arXiv:2607.20881v1 [cs.DB] 23 Jul 2026

Abstract Traditional graph processing systems are built on monolithic servers, which couple a fixed ratio of compute and memory resources but often result in resource under-utilization in data centers. Although the disaggregated memory (DM) architecture has emerged to address this inefficiency, we identify that existing graph processing systems on DM remain highly impractical. They rely on unscalable architectures that fail to scale beyond a single memory node and a single compute node, and they require compute-side caches that are orders of magnitude larger than conventional practice in DM. To this end, this paper presents DMG, the first practical graph processing system on DM, which demonstrates superior system scalability and cache efficiency while delivering high performance. To improve efficiency of graph retrieval on DM, DMG proposes a DM-friendly graph store with retrieval optimizations. To mitigate costly update propagation, DMG presents an adaptive update coordinator that coordinates compute and memory nodes to perform update propagation with low overhead. To enable fast and effective load balancing, DMG employs a two-stage workload manager that includes a coarse-grained initial partitioning and a finegrained runtime re-scheduling. Experimental results substantiate that compared with the state-of-the-art DM-based graph processing system, DMG can elastically scale up both compute and memory resources, delivering up to 4.9× better performance and accommodating graphs with ever-increasing sizes; meanwhile, it effectively tames the compute-side cache demands by up to 18.9×, positioning itself as a DM-ready solution in practice.

Introduction

Graph is a powerful abstraction for modeling complex relationships among entities and is essential in various applications, from traditional data analytics tasks (social networks, bio-informatics, and e-commerce transaction networks) to modern AI-related tasks (vector search [18, 24, 42, 49], recommendation systems [70], retrievalaugmented generation [12], and graph neural networks [56, 66, 73]). Especially, graph processing systems [8, 44, 54, 90, 92] have been widely studied as they embody optimizations for fundamental access and computation patterns on graph-structured data. Traditional distributed graph processing systems are built on monolithic servers [10, 15, 92], where different resource components (e.g., CPU and DRAM) are tightly coupled, scaled at a fixed rate, and lack sharing across physical servers. Such systems are inefficient in resource utilization (detailed in § 3.1). Specifically, to meet peak demand in either computation or memory capacity,

Zhisheng Hu

The Chinese University of Hong Kong [email protected]

Ming-Chang Yang

The Chinese University of Hong Kong [email protected] these systems allocate multiple monolithic servers, leading to overprovisioning of the other resource. Additionally, graphs need to be partitioned across isolated memories in traditional distributed systems, which require replicating boundary vertices. Recently, the disaggregated memory (DM) architecture has been proposed to improve resource utilization troubled by monolithic servers in data centers, attracting extensive attention from both academia [51, 63, 82, 85, 89] and industry [31, 57, 77, 78]. It decouples compute and memory components of monolithic servers into independent compute and memory pools bridged by fast and advancing interconnect technologies such as RDMA [58] and CXL [33]. The compute pool consists of compute nodes (CNs) with many CPU cores but little DRAM as cache, while the memory pool consists of memory nodes (MNs)1 with ample DRAM but few CPU cores. Thanks to its distinctive architecture, DM offers great potential to achieve high resource utilization for graph processing. Specifically, as compute and memory resources are decoupled, DM-based graph processing systems can on-demand provision compute and memory resources independently to meet diverse workload needs [35, 83]. Additionally, the large, shared memory pool of DM enables the maintenance of a unified graph view, which allows CNs to access a single copy of vertex data, thereby avoiding replication overhead. Unfortunately, we find that existing attempts for graph processing on DM [61, 83] remain highly impractical, as they fail to meet the criteria of DM and fall far short of leveraging DM’s benefits (§ 3.2). First, they are impractical for the unscalable system that ties execution to a single CN and a single MN. They cannot accommodate large graphs that exceed one MN’s memory or use computation power more than one CN can provide, contradicting DM’s promise of elastic scaling. Second, they are impractical for violating DM convention to over-demand compute-side cache. DM typically provisions limited cache per CN to retain independence in resource allocation, yet prior work [83] reports cache requirements of more than an order of magnitude higher for the clueweb12 dataset on one CN. More critically, such demand grows linearly with graph size and replicates across CNs when scaling out, thereby re-coupling resource allocation, amplifying resource usage, and nullifying the resource efficiency enabled by disaggregation. As summarized in Table 1, motivated by the resource inefficiency and impracticalities of existing systems, we aim to enable highperformance graph processing on DM with superior system scalability and DM-conventional cache demand. However, even with a 1We use server and node interchangeably: server mainly refers to traditional monolithic

server, while node mainly refers to memory/compute node in DM.

Yizou Chen, Tsun-Yu Yang, Zhisheng Hu, Baotong Lu, and Ming-Chang Yang

Table 1: Comparison of different graph processing systems.

Resource Utilization System Scalability DM Convention

Traditional Distributed

Existing DM-based

DMG (DM-based)

Bad Good –

Good Bad Bad

Good Good Good

V2 V3

(a) The Graph

[2] Read Idx [1] Check Activation Bitmap 1 0 0 0 0 V1 V2 V3 V4 V5 V1 V2 V3 V4 V5

Index 0 3 4 5 6 6

Edge V2 V4 V5 V4 V4 V5 List [3] Read Edge

(b) CSR Format

Attr val val val curr_iter val val [4]val Propagati on (Update) Attr val val val val val val next_iter

Figure 1: Data structures and workflow in graph processing.

2 Background 2.1 Graph Processing Graphs are commonly represented as 𝐺 = (𝑉 , 𝐸), where 𝑉 denotes the set of vertices, and 𝐸 ⊆ 𝑉 × 𝑉 is the set of edges. An edge (𝑢, 𝑣) connects two vertices, directed from the source vertex 𝑢 to the destination vertex 𝑣, where 𝑢 is the in-neighbor of 𝑣, and 𝑣 is the out-neighbor of 𝑢. For space efficiency, graph data is typically stored in the compressed sparse row (CSR) format (Figure 1(b)), which consists of an edge list array that stores the out-neighbors for all vertices in a contiguous manner, and an index array that records the starting position of each vertex’s edge list. Thus, to retrieve the edge list of a vertex v, the corresponding indices, 𝑖𝑑𝑥 𝑣 and 𝑖𝑑𝑥 𝑣+1 , are read from the index array, and then the associated edge list located between 𝑖𝑑𝑥 𝑣 and 𝑖𝑑𝑥 𝑣+1 in the edge data can be accessed. Based on the above-mentioned graph data structure, many graph algorithms have been proposed to extract meaningful information. These algorithms typically maintain two vertex attribute arrays to hold vertex states/values for the current and next iterations (Figure 1(c)). In each iteration, vertices that are active according to the algorithm’s rule propagate their attribute values along outgoing edges to update their neighbors. As shown in Figure 1, a typical iteration involves four steps: (1) checking vertex activation, (2&3) accessing corresponding indices and edge lists, and (4) propagating attribute values to neighbors. The algorithm ends when no vertices remain active or a predefined convergence condition is met. We refer to this whole procedure as graph processing (or graph analytics). Notably, a vertex’s neighbors are often scattered across the graph’s data layout, and a destination vertex may be updated by multiple sources. This leads to highly random and contended memory accesses, posing a fundamental challenge for graph processing.

2.2

Disaggregated Memory (DM)

Abundant CPU cores Scarce DRAM

Compute Nodes (Pool)

LXC / A MDR

sensible partitioning scheme (as discussed in § 3.3), it is non-trivial to realize high performance with the practical architecture that fully reaps the benefits of DM. In particular, three key challenges remain: (1) Retrieving graphs from DM exhausts network. The randomness, dependency, and fine granularity of graph accesses generate numerous small remote requests, quickly saturating RDMA’s limited IOPS capacity and limiting performance. (2) Remote updates to DM are unavoidable yet costly. The skewed connectivity in real-world graphs makes it impossible for partitioning to fully avoid edges targeting outside a CN’s cache [7, 86]. Although only a small fraction of edges trigger remote updates, they can still cause substantial slowdown since RDMA atomic operations are far more costly than local ones. (3) DM urges fast and effective load balancing. Existing graph partitioning methods for inter-CN balancing are time-consuming, making them impractical for DM where resources are frequently reconfigured. Within each CN, severe tail effects arise since hub-vertices with long edge lists amplify the impact of high-latency RDMA operations. To address the above challenges, this paper presents DMG, the first practical Graph processing system on Disaggregated Memory, which demonstrates superior system scalability and cache efficiency while delivering high performance. DMG incorporates three key and innovative designs: First, to achieve efficient graph retrieval, DMG presents a DM-friendly graph store, redesigning the traditional CSR format to alleviate the IOPS bottleneck by merging reads of indices and edge-lists/metadata. Second, to address the costly update propagation, DMG proposes an adaptive update coordinator. For dense iteration, it applies collaborative update that takes cache affinity into consideration and runtime re-distributes update candidates to the node that is more suitable to handle them. For sparse iteration, it switches to direct remote update, eliminating synchronization overhead. Third, to achieve fast and effective load balancing, DMG employs a two-stage workload manager. At startup, DMG finds the coarse-grained partitioning can be fast while not compromising effectiveness. At runtime, DMG applies fine-grained re-scheduling to mitigate tail effect induced by hub-vertices. We implement DMG and evaluate it using various algorithms and billion-scale graphs. Our results reveal that, compared with the state-of-the-art graph processing system on DM, DMG can elastically and independently scale up compute and memory resources, delivering up to 4.9× better performance and accommodating graphs with ever-increasing sizes; meanwhile, it effectively tames the compute-side cache demands by up to 18.9×, positioning itself as a DM-ready solution in practice. Code will be open-sourced.

Scarce CPU cores Abundant DRAM

Memory Nodes (Pool)

Figure 2: The Disaggregated Memory Architecture. The disaggregated memory (DM) architecture has recently been proposed for cloud infrastructure [45, 51] to address the resource inefficiency in traditional data centers built on monolithic servers, which couple different resource components together [19, 37, 57]. As shown in Figure 2, DM decouples compute and memory resources into separate compute and memory pools. The compute

DMG : A Scalable and Efficient Memory-Disaggregated Graph Processing System

V3 V1

V4 V5 V6

(a) The Graph

Vi Master Vertex Vj Mirror Vertex (Replication) CN1 On-demand CNn V5 V1 V3 V2 V3 V5 V1 On-demand On-demand V6 V2 V4 Subgraph 1 on Server 1

V4 V5 Subgraph 2 on Server 2

V3 V6 Subgraph 3 on Server 3

(b) Traditional Distributed Graph Processing

Allocate

Fetch

Full Graph: V1 V2 V3 V4 V5 V6 Memory Nodes (Pool)

Figure 3: An example of vertex replication in distributed graph processing systems. DM-based graph processing places the graph on the large shared-accessible memory pool. pool consists of compute nodes (CNs) with abundant CPU cores but scarce DRAM as local cache (e.g., 1–2 GB) [40, 62]. The memory pool, on the other hand, comprises memory nodes (MNs) with adequate DRAM yet weak computation power (e.g., 1–2 CPU cores) [21, 36, 62]. The two pools are connected by advanced interconnect techniques with ever-increasing speed, such as remote direct memory access (RDMA) [58] or compute express link (CXL) [33]. By allocating different resources from the pools on-demand and independently, DM improves resource utilization and has become an important paradigm in industry [31, 78]. Notably, virtualization cannot fully address resource under-utilization: once a server’s CPU cores are all rented, its remaining memory cannot be leased [32]. Following prior works [4, 21, 36, 39, 40, 52, 62], this paper focuses on RDMA-based DM, as CXL 3.0 devices that enable memory pooling and sharing are not yet available. RDMA offers RDMA verbs for developers to use, which include both one-sided verbs (READ/WRITE/CAS/FAA) and two-sided verbs (SEND/RECV). One-sided verbs enable direct remote memory access without involving the remote CPU, whereas two-sided verbs require remote CPU participation and can support more complex operations, such as memory management [52, 53, 62] and selective offloading tasks [21, 29, 36, 95].

3 Observation and Motivation 3.1 Graph Processing: Distributed vs. DM

Figure 3(b)2 shows how vertices are replicated across servers in distributed graph processing systems. Vertices are initially assigned to different subgraphs (servers), and each server keeps the master copy of its assigned vertices [7, 10, 15, 92]. The edges associated with a master vertex are also assigned to the same subgraph (server). Once the graph is distributed across servers, a server may need to process edges that touch vertices whose master copies reside on other servers. Existing systems therefore create local replicas of such vertices, called mirror vertices, to support processing on partitioned subgraphs. At the end of each iteration, mirrors synchronize with their master copies. This phenomenon incurs non-negligible memory overhead, because finding a balanced partition with few cross-subgraph edges is NP-hard [86], making replicas hard to avoid, while each replica also consumes extra memory for index and data of vertices [13]. For example, on 4 servers with vertex replication, Gemini [92] uses 2.7× and 2.0× more memory for vertices than on a single server for twitter-2010 and clueweb12 graphs, respectively. 3.1.2 Advantages of DM-based Graph Processing. DM-based graph processing systems can resolve the aforementioned issues. First, for resource over-provisioning, DM enables on-demand allocation of compute and memory resources beyond the capacity of a single machine, better matching varying workload demands in a cost-efficient manner. Second, DM can natively mitigate vertex replication, whose root cause is the isolated and capacity-limited local memory of monolithic servers. In distributed graph processing systems built on monolithic servers, graph data must be physically partitioned across servers, and replicas are introduced at partition boundaries to enable distributed execution. By contrast, DM provides a large shared memory pool directly accessible by multiple CNs. The graph can thus be stored in DM with a unified view, allowing multiple CNs to access a single copy of vertex data on demand (Figure 3(c)) rather than maintaining replicas across servers. It in turn reduces the need for vertex replication and the associated memory overhead.

3.2 3.1.1 Issues of Distributed Graph Processing. Distributed graph processing systems have limitations in resource utilization, particularly in terms of resource over-provisioning and vertex replication. Resource Over-Provisioning. Existing distributed graph processing systems are built on monolithic servers, where CPU and DRAM are tightly coupled, scaled at a fixed ratio, and cannot be shared across physical servers. Such coupling is a well-known source of resource under-utilization in data centers [19, 37, 57]. Tenants often need to over-provision servers to satisfy peak demand in either computation power or memory capacity. Specifically, first, users may allocate multiple servers to achieve higher performance, while much of the attached memory remains under-utilized. Second, large graphs that cannot fit in a single server require multiple servers for memory capacity, even though the coupled CPU resources may be under-utilized, e.g., for sparse queries. Vertex Replication. Moreover, we identify vertex replication as another issue in distributed graph processing. Distributed graph processing systems typically partition the graph into multiple subgraphs and assign them to be held and processed by different servers.

Progress & Limitations of Existing Systems

Recently, FAM-Graph [83] and Fargraph [61] made early attempts at graph processing on DM. Both systems offload edge data to RDMA-attached remote memory. FAM-Graph follows the design of single-machine in-memory graph processing systems [44, 54], operating at a fine-grained per-vertex level. In contrast, Fargraph is built on a storage-based graph processing system [93], benefiting from coarse-grained sequential access but failing to exploit DM’s fine-grained on-demand access capability. Unfortunately, we found that existing works, both FAM-Graph and Fargraph, are severely impractical considering system scalability and compute-side cache demands. Consequently, they fall short of meeting the criteria and realizing the benefits of the memorydisaggregated architecture.

2 Graph partitioning methods are generally categorized into edge-cut and vertex-cut. We use edge-cut partitioning as an example here, since it is widely used and has been shown to perform well in practice [14]. Vertex-cut partitioning also naturally introduces vertex replication and thus does not change our motivation.

Yizou Chen, Tsun-Yu Yang, Zhisheng Hu, Baotong Lu, and Ming-Chang Yang

DRAM in CN

CNLarge DRAM V

Network

CNs

Unscalable

X MNs

V Vertex Data

(Index, Attribute, Bitmap)

E (a) Existing Work (FAM-Graph)

Edge Data

CN1 Small DRAM ...... Small DRAM CNn

MN1

Network

......

V E (b) Ours

MNm

Figure 4: Different system architectures and data layouts for graph processing systems on DM. Existing works are unscalable and over-demanding of compute-side cache. Impracticality 1: Unscalable system. Notably, both FAM-Graph and Fargraph are restricted to a single CN and a single MN (Figure 4(a)), unable to scale to multiple CNs or MNs. Such restrictive architecture is unacceptable. First, it fails to handle large graphs which can easily exceed the memory capacity of a single MN. Second, it confines computation to the CPU cores of a single CN, resulting in long execution times for large graphs. These constraints contradict the core objective of DM: enabling elastic resource provisioning to support diverse datasets and workload requirements. Moreover, they have not answered the questions of how to place graph data across MNs, how to distribute workloads among CNs, and how to handle concurrent updates from CNs to MNs. Unlike multiple threads within a single CN, accesses from CNs to MNs are both costly and lack native cache coherence, making this setting more challenging. Impracticality 2: Violating DM convention to over-demand compute-side cache. To the best of our knowledge, DM systems assume only limited memory capacity (e.g., 1-2 GB) in CNs as local cache, thereby improving resource utilization by decoupling allocation of memory from computation resources. However, both FAM-Graph and Fargraph require substantial amounts of memory in each CN to hold the entire CSR index and all vertex attributes, which is impractical and misaligned with the DM architecture. As reported in FAM-Graph, processing the clueweb12 dataset requires 22.5 GB of cache per CN [83], which is over an order of magnitude higher than typical DM configurations. Crucially, this is not a fixed overhead: the required compute-side cache scales linearly with both the number of vertices and the number of CNs, i.e., 𝑂 (|𝑉 | ∗ #𝐶𝑁 ). As a result, processing larger graphs or applying more CNs proportionally increases the total compute-side memory usage. This scaling re-couples memory allocation with CNs and can make aggregate CN memory usage rival or exceed MN usage, violating the goal of disaggregating memory from compute.

3.3

Challenges

Based on the impracticalities of existing works, our goal is to build a graph processing system on DM that can scale to multiple CNs and MNs, require limited compute-side cache, and achieve high performance. Figure 4(b) shows our target system architecture and data layout. All data in graph processing, including both edge data and full vertex data (indices, current- and next-iteration vertex attributes), reside in the DM pool made up by multiple MNs. The DM pool is viewed as a global address space shared by multiple

CNs, addressed via a 16-bit MN ID and 48-bit in-MN offset, as prior works [40, 62]. Each CN uses only a small DRAM (smaller than vertex data size) as explicitly managed cache to run large graphs. Since this is still an unexplored problem, as a first step, we draw inspiration from traditional distributed graph systems and find that the chunk-based partitioning encourages a sensible approach for scaling graph processing to multiple nodes with constrained compute-side cache. Typically, distributed graph systems [7, 10, 15, 92] partition vertices across servers, and each server executes the processing logic for its assigned vertices. Gemini [92] further exploits the empirical locality in large real-world graphs: neighboring vertices tend to reside near to each other. Considering this property, Gemini introduces chunk-based partitioning, which divides the vertex set into 𝑝 contiguous, disjoint chunks, each assigned to one server. This layout offers good computation locality and keeps lots of update propagation within each server. Based on the locality preserved in chunkbased partitioning, a sensible approach for graph processing system to scale to multiple nodes with constrained compute-side cache is: each CN caches only the corresponding chunk’s next-iteration vertex attributes, which is randomly touched as shown in Figure 1(c). This approach offers three benefits: • A high fraction of random neighborhood updates can be absorbed by the CN cache thanks to locality in chunk, reducing remote accesses to MNs. • Since it demands the CNs’ aggregate memory to be compatible for a single attribute array, the system can process large graphs under tight CN cache and always scale to handle larger graphs by adding CNs or MNs as needed. For example, with 4 CNs, we require about 1 GB cache per CN for the largest clueweb12 dataset, an order of magnitude less than FAM-Graph, while aligning with typical DM architectures. • Different CNs cache disjoint subsets of vertex attributes, simplifying cache-coherence management. Built on the practical DM architecture and data layout for graph processing described above, several challenges still impede achieving high performance. Challenge 1: Retrieving graph from DM exhausts network. Placing graph data on MNs forces CNs with limited local cache to perform costly remote memory accesses. The overhead of remote accesses becomes more severe considering the nature of graph workloads, whose access patterns are notoriously random, dependent, and fine-grained. (1) Randomness. The neighbors of a vertex are typically scattered randomly in the graph file. Thus, graph processing often involves accessing arbitrary memory locations in an irregular pattern. (2) Dependency. Retrieving edges of a vertex requires two dependent high-latency remote accesses: one to fetch the index for the address and length of the edge list and a subsequent one for the edge data. Such dependency doubles latency for each vertex traversal. (3) Fine granularity. Specifically, graph data elements like vertex attributes and index entries are typically small, just a few bytes. Moreover, edge lists of most vertices are short due to the power-law degree distributions common in real-world graphs [15]. Collectively, these characteristics lead to massive small remote accesses, which clashes with RDMA’s limited IOPS capacity. Figure 5 summarizes the access granularity during a graph traversal after merging contiguous accesses (e.g., two adjacent required

8k 32k

IOPS bound

10 1

Access Granularity (Bytes)

32 128 512 2k

8k 32k

Access Granularity (Bytes)

Figure 5: CDF of access granu- Figure 6: IOPS and bandwidth larity for graph retrieval dur- of RDMA_READ [1] for different ing BFS on twitter-2010 access granularity edge lists are fetched in one operation). Over 94% of accesses are not larger than 256 B. However, as Figure 6 shows (measured by perftest [1]), RDMA NICs are IOPS-bound for such small accesses (e.g., <4 KB), where protocol overheads dominate performance. Challenge 2: Remote updates to DM are unavoidable yet costly. Due to real-world graphs’ skewed degree distributions and cross-cutting connectivity, no graph partitioning method (including chunk-based method) can always yield perfectly isolated and size-balanced sub-graphs [7, 86]. As a result, a substantial fraction of edges inevitably span partitions. Consequently, when a CN processes such edges whose destination vertices lie outside its cached subset, update propagation along such edges requires a CN to perform remote update to corresponding vertex attribute on DM. Unfortunately, remote updates are far more costly than local ones. Since multiple vertices can connect to the same vertex, multiple updates towards the same vertex attribute can be generated from multiple CNs. To ensure correctness, DM systems typically use RDMA atomic operations (RDMA_CAS and RDMA_FAA) to enable concurrent updates from CNs [39, 62]. However, the remote updates based on RDMA atomic operations are costly for two reasons. First, the RDMA atomics are fine-grained, which can contend for limited network IOPS. Second, they risk failures and retries by CNs’ concurrent updates, further pressuring the network. Table 2 quantifies the impact under a full-activation iteration: despite chunk-based partitioning, only a small fraction of edges require remote updates (1.83–54.1% for real-world graphs), yet they induce a substantial slowdown compared to an idealized all-local baseline (19.4–39.6×). Furthermore, in real graph processing workloads, update volumes incurred by different vertices or across different iterations are highly variable, precluding one-size-fits-all solutions. Table 2: Ratio of direct remote updates and corresponding slowdown rate (relative to local-only updates) using chunkbased partitioning in a fully-activated iteration (4 CNs). Dataset

R29

Ratio Slowdown

54.1% 39.6×

1.83% 19.4×

72.0% 28.4×

6.04% 29.7×

Preprocessing

100

Challenge 3: DM urges fast and effective load balancing. Although load balancing is an essential and well-studied topic for traditional parallel systems, graph processing on DM presents unique challenges, making existing methods ineffective. (1) Inter-server load balancing typically relies on graph partitioning during the startup phase to build balanced subgraphs assigned to different

Computation

98.03%

R29

98.56%

99.64%

97.01%

Time Ratio (%)

100

Thread Exec Time (s)

32 128 512 2k

IOPS (Million/sec)

CDF

Bandwidth bound

Datasets

IOPS Bandwidth

CDF

1.0 0.8 0.6 0.4 0.2 0.0 8

Bandwidth (Gbps)

DMG : A Scalable and Efficient Memory-Disaggregated Graph Processing System

Max w/o coro Avg w/o coro

Max w/ 4-coro Avg w/ 4-coro

1 0 1-3

Iteration Number

9 10-17

Figure 7: Preprocessing Figure 8: Execution time across time ratio in Gemini (4 threads in baseline DM graph sysservers, PageRank): exist- tem (1 CN; BFS; TW): both w/o ing methods have long and w/ coroutines, the maximum startup time. thread execution time is significantly longer than the average.

servers. Unfortunately, as shown in Figure 7, state-of-the-art systems like Gemini [92] require prohibitively long preprocessing time, greatly surpassing end-to-end gains. This slow startup is especially problematic for DM, where systems may adaptively adjust compute resources to optimize resource efficiency, necessitating repeated system reconfiguration. (2) Intra-server load balancing is further complicated by the high latency of remote memory accesses on DM. We first build a baseline system using the intra-server workload manager from a state-ofthe-art design [92]: each thread is initially assigned a set of vertices to process and, once finished, steals additional vertices from others. As shown in Figure 8, execution times vary significantly: the slowest thread becomes a clear outlier, bottlenecking overall progress. Introducing coroutines within each thread (details in § 4.5.1) hides some RDMA latency, but the tail effect persists. This stems from the interaction between hub-vertices and high-latency RDMA operations. Real-world graphs with skewed degree distributions naturally contain hub-vertices that connect to an unusually large number of other vertices. Processing them triggers numerous high-latency RDMA operations, leading to pronounced tail latency. Coroutines offer limited relief: while they expose asynchronous execution, they can also concentrate multiple hub vertices in the same thread.

4 DMG Design 4.1 Overview We propose DMG, the first practical graph processing system on DM with system scalability, cache efficiency, and high performance. Figure 9 shows the overview of DMG. DMG decomposes graph processing workflow into four key steps and its designs comprehensively cover all of them: loading graph to DM(❶), workload assignment (❷), graph retrieval (❸), and update propagation (❹). DMG incorporates three designs to address the challenges outlined earlier. First, for Challenge 1, DMG presents the DM-friendly graph store in § 4.2 to enable efficient placement and retrieval of graph data on DM. The storage format also forms the basis for subsequent components. Second, to resolve the complexities of concurrent remote updates from multiple CNs (Challenge 2), DMG proposes an adaptive update coordinator in § 4.3. Third, to tackle Challenge 3, DMG employs a two-stage workload manager in § 4.4 to achieve fast and effective load balancing both across and within CNs. Finally, § 4.5 presents optimizations and discussion.

Yizou Chen, Tsun-Yu Yang, Zhisheng Hu, Baotong Lu, and Ming-Chang Yang

laveirteR

g ni d a o L

sedo N p mo C sedo N me M 1

2 Assign 2-Stage Workload... Manager (§ 4.4) 4 Update 3

Adaptive Update Coordinator (§ 4.3) Vertex Attribute

DM-friendly Graph Store (§ 4.2)

Figure 9: The Overview of DMG.

Single Index Array : Vertex 0 Index Vertex 1 Index Per-Vertex Index: 4 B 4 B 4 B 32 B In-place Scheme

Out-of-place Scheme

Degree Edge

Edge

4B 8B Degree Edge List Addr 16 bit 48 bit MN ID Offset

Decoupled Placement

Edge

Vertex 2 Index . . . . . Edge

Logical Partition

......

1-4 B 1-4 B Seg Len Seg Len Seg Len ...... 2 bit (8k-2) bit #Byte Segment Length Out-of-place Edge List

Figure 10: The DM-friendly Graph Store.

4.2

DM-friendly Graph Store

The storage format fundamentally determines the efficiency of storing and accessing graph data on DM. Figure 10 shows DMG’s DM-friendly graph store. (1) DMG stores vertex data (indices and attributes) only once by a single array on DM, without replication in each CN or MN. (2) DMG redesigns the CSR format with an adaptive index scheme (§ 4.2.1) to improve retrieval efficiency and enable multi-node coordination. (3) Moreover, two optimizations (§ 4.2.2) are applied to enhance graph retrieval on DM. (4) Lastly, we detail the process and layout of loading graph to DM in § 4.2.3. 4.2.1 Adaptive Index Scheme. As revealed in Challenge 1, retrieving graph data from DM incurs substantial overhead, as frequent small remote accesses stress the limited IOPS of RDMA networks. DMG addresses this issue via an adaptive index scheme that aligns graph data with hardware characteristics. Our key insight is to alleviate the IOPS bottleneck by placing the indices and low-degree edge lists together, turning many finegrained RDMA reads into fewer, larger transfers. Specifically, since RDMA throughput for small requests is limited by IOPS [25] rather than bandwidth, increasing the access size per request enables more data to be transferred at the same IOPS cost. Moreover, the powerlaw degree distribution in real-world graphs, while it naturally leads to many fine-grained accesses on abundant low-degree vertices, also creates an opportunity: the small edge lists of these vertices can fit within a single, RDMA-efficient index block. Building on these observations and inspired by prior works on multi-level graph store [26, 41, 46, 81], we redesign the classic CSR format for graph retrieval on DM. Instead of storing a single offset per vertex, we employ an expanded index structure with larger size (32B in this work, chosen to balance performance and memory efficiency; see Figure 22) that can either embed edges directly or store metadata for an out-of-place edge list. As illustrated in Figure 10, DMG chooses the in-place or out-of-place scheme for each vertex by comparing its recorded degree with the maximum number of edges that can fit in one index entry. By slightly enlarging each RDMA request, DMG obtains auxiliary information without additional network overhead, since the cost is dominated by the number of RDMA operations rather than their size. In-place edge index scheme. For vertices with few edges, DMG stores the edge list directly in the index structure, identified as the inplace scheme. Edges are fetched via a single RDMA read rather than two as in traditional CSR-based graph systems. Because real-world graphs are highly skewed, a large fraction of vertices have only a few neighbors and can be inlined with little memory overhead. For example, in the twitter graph [27], the average degree is 39, while

65% of vertices have fewer than 10 edges, making them natural candidates for the in-place scheme. Out-of-place edge index scheme. For high-degree vertices whose edge lists cannot fit within the index structure, DMG adopts an out-of-place scheme: as shown in Figure 10, each index entry stores the vertex degree, the global address of out-of-place edge list in the DM pool (16-bit MN ID + 48-bit offset in the MN), and persegment lengths. The out-of-place scheme includes three design concepts. First, each edge list is logically partitioned into segments, where each segment contains edges whose destination vertices fall within a specific partition range (§ 4.4.1). The index explicitly records the length of each segment, allowing the system to identify and access the segment of edge list relevant to a given partition, which is crucial for efficient multi-node coordination (§ 4.3). Second, to reduce space overhead, we compress segment lengths using variable-length encoding: the first two bits indicate the number of bytes (1-4) used, and the remaining bits store the segment length. As Figure 23 shows, most segments fit within a single byte, keeping the index structure compact. For extreme cases requiring more segments, the index can use more bytes per entry, incurring only limited space overhead (Figure 22). Finally, the out-of-place edge lists are distributed independently of the vertex index across MNs to avoid hotspots in memory usage and network bandwidth caused by clustering of high-degree vertices. 4.2.2 Optimization: Merged and Batched Retrieval. DMG accelerates graph retrieval from DM using two optimizations: merging and doorbell batching [68, 83]. Merging combines multiple reads from contiguous memory into a single RDMA operation. Doorbell batching allows the RNIC to fetch multiple requests by one DMA and signal completion only once. Together, these techniques improve network and PCIe utilization while reducing CPU overhead. Figure 11 shows DMG’s approach: each worker processes a batch of consecutive vertices at a time. Instead of operating vertex by vertex, DMG adopts a batch-oriented workflow across all steps (activation check, index and edge-list retrieval) to reduce RDMA invocation overhead. After batch-level activation checks, DMG issues RDMA reads for indices of all active vertices, merging requests to contiguous regions and grouping them into doorbell batches. Once the indices are fetched, DMG identifies entries that reference outof-place edge lists and similarly issues merged and batched RDMA reads for those edges. Notably, edge lists of consecutive vertices with the out-of-place scheme are placed contiguously during graph loading, ensuring batched reads either cover continuous regions or, at least, remain within the same MN. This locality is essential, as

DMG : A Scalable and Efficient Memory-Disaggregated Graph Processing System

In-place Index Out-of-place Index Index of Active Vertex Out-of-place Edge List

Batched RDMA Request Merged Index Read

2 Merged [+Batched] OOP Edge Read

Figure 11: Merged and batched retrieval of graph data. doorbell batching requires requests to be issued to the same RDMA queue pair (i.e., same MN). 4.2.3 Loading Graph to DM. DMG leverages the large, globally addressable DM pool to simplify graph loading. It loads and stores the edge list of each vertex in a continuous region on a single MN without scattering a vertex’s edges across servers to construct subgraphs. When building the graph store on DM from a graph in CSR format on a storage device, it proceeds as follows. First, DMG allocates a shared vertex index array in DM, which serves as the unified entry point for all edge data and is accessible by all CNs. The array is range-partitioned across MNs: each MN stores a contiguous subset of vertex indices based on partitioning results. DMG allocates the vertex attribute array using the same policy. Then, threads in CNs populate the graph store in parallel. Each thread loads a batch of vertices at a time and reads their edges from the CSR input. For low-degree vertices, edges are embedded directly in the index structure. For high-degree vertices, DMG allocates outof-place memory space for the edge lists from the DM pool and records the addresses and segment lengths in the index structure. To balance memory usage across MNs, the allocator for edges selects MNs in a coarse-grained round-robin manner. Out-of-place edge lists in the same batch are allocated in contiguous memory regions in one MN. After processing a batch, the thread writes the updated index entries to DM by a single RDMA operation.

4.3

Adaptive Update Coordinator

For update propagation, which encounters Challenge 2, we propose an adaptive update coordinator that adaptively chooses between different update strategies based on update density, cache affinity, and vertex characteristics. As shown in Figure 12, when an iteration has dense updates (many active vertices), DMG employs a novel Collaborative Update scheme (§ 4.3.1), a key contribution of this work. This scheme exploits cache affinity across CNs and MNs, and runtime redistributes update candidates that cannot be handled locally to nodes that can process them using local memory accesses. The re-distribute (RD) mechanism combines two complementary patterns, Pass-by-Value and Pass-by-Reference. When an iteration has sparse updates (few active vertices), DMG switches to a Direct Remote Update scheme (§4.3.2), which simplifies execution and removes synchronization overhead.

an iteration

Dense? No

Yes Collaborative Update (§4.3.1) Direct Remote Update (§4.3.2)

Local Update Pass-by-Reference Re-Distribute Pass-by-Value Re-Distribute

Figure 12: Different strategies in DMG to perform update propagation in graph processing.

CN1:Vertex Range [0, t1]

(1) Hit Vertex [0, t0] Attr (2.2) RD: Pass by Value

RefRD Bufs ValRD Bufs

......

CNn: Vertex Range [tn-1, N] Vertex [tn-1, N] Attr (3) Pull & Process

(2.1) RD: Pass by Reference ...... RefRD Bufs

Vertex Attr Array Graph Index & Edge List

ValRD Bufs

[OptiUpdate onal] Local

Figure 13: An example of Collaborative Update: how to process the update candidates initially generated from 𝐶𝑁 1 . 4.3.1 Collaborative Update. DMG introduces a Collaborative Update scheme for iterations with dense updates, which dominate the end-to-end execution time of graph processing workloads. Notably, as analyzed in § 3.3, chunk-based partitioning encourages an effective compute-side caching strategy: each CN caches only the attributes of vertices in its assigned chunk. This strategy ensures a high fraction of updates can hit the cache while requiring only limited compute-side cache, even for increasingly large graphs. However, as revealed in Challenge 2, performance bottlenecks persist due to costly remote memory operations when updates target vertices that are not cached. We identify two properties of chunk-based caching that open new opportunities in the design space: (1) The attribute of each vertex is guaranteed to be cached at some CN and stored at some MN; (2) The CN or MN holding the attribute of a given vertex can be quickly located via the partition offsets. Therefore, our key insight is that we can pass uncached update candidates3 to the CN or MN that already holds the corresponding vertex attributes, and let that node execute the update logic via local memory operations. In other words, we move updates to where the data resides via large sequential accesses, rather than forcing the CN that initially generates the update candidates to execute the update logic through costly random remote memory operations. Since the passing process can batch information about many update candidates into a few coarse-grained sequential RDMA_WRITE/READ, its overhead is substantially lower than directly executing finegrained update logic over the network. As illustrated in Figure 13, consider a source vertex 𝑣 processed by 𝐶𝑁 1 , which belongs to the partitioned chunk 𝑉1 ⊆ 𝑉 . 𝐶𝑁 1 loads and caches the attributes of vertices in 𝑉1 . When processing 𝑣’s edge list, if a destination vertex also resides in 𝑉1 , the update is performed directly on 𝐶𝑁 1 , i.e., Local Update. If the destination vertex belongs to another chunk, e.g., 𝑉𝑛 , the update candidate is re-distributed to the responsible 𝐶𝑁𝑛 or corresponding MN, which then executes the update locally, i.e., Re-Distribute Update. Re-Distribute (RD) includes two patterns: Pass-by-Reference Re-Distribute (RefRD) and Pass-by-Value Re-Distribute (ValRD). Pass-by-Reference Redistribute. For vertices with long uncached edge-list segments, DMG adopts pass-by-reference redistribution (RefRD). Instead of transferring the entire edge list, RefRD transmits only metadata for each relevant segment, including the 3 An update candidate indicates the attribute of the active source vertex and the desti-

nation vertices (edges) to be updated.

Yizou Chen, Tsun-Yu Yang, Zhisheng Hu, Baotong Lu, and Ming-Chang Yang

Slot 16 bit

Batched RefRD Buffer (e.g., 4 KB)

Slot ...... 4B e.g., 4 B Edge Seg Edge Seg Length Source Vertex MN ID Offset in MN Attribute 48 bit

Slot

Batched ValRD Buffer (e.g., 32 KB) Slot

Slot Slot ...... 4B e.g., 4 B Edge Source Vertex (Dst Vertex ID) Attribute

(a) RD structure of passing by reference: at the (b) RD structure of passing by granularity of an edge segment. value: at the granularity of an edge

Figure 14: Structure of Batched Re-Distribution (RD) Buffer

segment’s starting address, length, and source vertex attribute, as illustrated in Figure 14(a). The pre-embedded segment lengths introduced in § 4.2.1 enable quick identification of the relevant segments for destination vertices within a given partition (chunk). Segments whose destination vertices fall into different ranges are passed to different CNs. RefRD items are buffered at the sender CN and flushed to the corresponding MN either when the buffer is full or upon completion of the CN’s workload. Each CN uses a thread to pull the RefRD buffer passed from other CNs. Upon receiving RefRD items, the CN retrieves the corresponding long edge-list segment from DM and applies updates to the destination vertex attributes cached in its local memory. Pass-by-Value Redistribute. For vertices with short edge lists embedded in the index (e.g., degree ≤ 7), as well as for long edge lists where only a small fraction of segments (e.g., segments with ≤ 7 edges) fall outside the CN’s partition, DMG uses pass-by-value redistribution (ValRD) instead of RefRD. As Figure 14(b) shows, each ValRD item contains the source vertex attribute and the destination vertex ID. Similar to RefRD, ValRD items are also buffered, transferred, and processed in batches to eliminate fine-grained RDMA operations. Unlike RefRD, which requires accessing out-of-place edge lists, ValRD items already carry the information needed for update propagation. Therefore, these updates can be performed locally when the limited computation power of MNs is available and under low stress [21, 29, 36]. As confirmed by experiments, a single MN thread can handle the offloaded ValRD items and perform updates locally with limited CPU usage. Critically, the two RD patterns are complementary under the power-law degree distributions prevalent in real-world graphs, where most vertices have only a few edges while a small number of vertices have extremely many edges. Using only one pattern performs poorly, whereas combining both is essential for efficiency. (1) A RefRD-only design would generate a large number of references for low-degree vertices, forcing each receiver CN to issue costly fine-grained reads for every small segment. (2) A ValRD-only design is inefficient for high-degree vertices, as it must transfer large volumes of raw edge data, stressing network bandwidth and potentially saturating the MN’s limited compute capacity. At the end of each iteration that uses the collaborative update scheme with RD, CNs merge (evict) their local cached copies of vertex attributes with the attributes in the remote memory pool. The merging (eviction) is performed sequentially and without interCN contention, significantly improving over issuing fine-grained remote updates directly. Notably, although RD relies on the partitioning result to determine the destination CN, and partitioning is embedded in the

graph store (the out-of-place scheme), RD does not necessitate repartitioning the graph or reloading the graph store whenever the number of CNs changes. Instead, the partitioning result and the graph loaded in DM can be reused across different CN counts. With fewer CNs, a graph store originally built for a larger number of partitions can be reused by aggregating multiple partitions. With more CNs, the CNs can be organized into multiple groups that share the same graph store in DM. For example, when scaling from 4 CNs to 8 CNs, the CNs can be organized into two 4-CN groups that reuse the same loaded graph. 4.3.2 Direct Remote Update. In many graph workloads, most iterations activate only a very small fraction of vertices (i.e., few updates). For example, in a breadth-first search on the clueweb12 dataset, convergence occurs in about 500 iterations, yet in fewer than 50 iterations more than 0.01% of vertices are activated for processing. During such sparse iterations, CNs do not cache vertex attributes; instead, they perform updates directly via remote memory accesses for simplicity and efficiency. Since RDMA provides only limited atomic operations (RDMA_CAS, RDMA_FAA), updating a vertex attribute, such as writing a smaller value, requires multiple RDMA operations. Specifically, the CN first reads the current vertex attribute from remote memory and compares it locally; if an update is needed, it repeatedly issues RDMA_CAS until the update succeeds or becomes unnecessary.

4.4

Two-Stage Workload Manager

To address Challenge 3, DMG employs a two-stage workload manager that operates across and within CNs. The coarse-grained initial partitioning (§ 4.4.1) counteracts the prohibitive preprocessing overhead, while the fine-grained runtime re-scheduling (§ 4.4.2) alleviates the long-tail effect. 4.4.1 Coarse-Grained Initial Partitioning. Generally, DMG follows chunk-based partitioning [92] to achieve inter-CN load balancing: the vertex set is divided into subsets, and each subset of vertices is assigned to be processed by a CN. Formally, given a graph 𝐺 = (𝑉 , 𝐸), the vertex set 𝑉 = {𝑣 0, . . . , 𝑣𝑛−1 } is divided into 𝑝 disjoint, contiguous subsets (partitions) 𝑉0, 𝑉1, . . . , 𝑉𝑝 −1 such that: Ð𝑝 −1 • 𝑉 = 𝑖=0 𝑉𝑖 with 𝑉𝑖 ∩ 𝑉𝑗 = ∅ (𝑖 ≠ 𝑗) • 𝑉𝑖 = {𝑣 𝑗 | 𝑡𝑖 ≤ 𝑗 < 𝑡𝑖+1 }, for 0 = 𝑡 0 < · · · < 𝑡𝑝 = 𝑛 We apply the same objective function as Gemini [92], trying to balance the value of 8 ∗ (𝑝 − 1)|𝑉𝑖 | + |𝐸𝑖 |across partitions. |𝑉𝑖 | is the vertex number and |𝐸𝑖 | is the number of edges associated with 𝑉𝑖 . Our key observation is that vertex-level granularity in chunkbased partitioning is unnecessary and expensive when |𝑉 | ≫ 𝑝. Existing methods traverse the full graph to gather per-vertex statistics, yet a graph often contains millions or billions of vertices while the partition count 𝑝 is only in the single or low double digits. The finest granularity marginally improves load balance but incurs a major partitioning cost. To address this inefficiency, DMG introduces the coarse-grained initial partitioning. We first slice the vertex set into a fixed number (e.g., 1024) of contiguous tiny-chunks and record lightweight metadata for each tiny-chunk, including vertex and edge counts. Partitioning then manipulates only this metadata: DMG assembles tiny-chunks into 𝑝 partitions and assigns them to CNs without

DMG : A Scalable and Efficient Memory-Disaggregated Graph Processing System

revisiting the full edge list. The reusable tiny-chunks’ metadata enables rapid re-partitioning when the DM system adjusts resources. To our knowledge, this is the first graph partitioning method that operates at the coarse granularity of tiny-chunks, rather than at the traditional vertex level. 4.4.2 Fine-Grained Runtime Re-Scheduling. After initial (chunkbased) partitioning which divides the vertex set into multiple subsets and assigns each subset to a CN for processing, DMG uses a fine-grained runtime approach within each CN to balance workload across threads and mitigate tail latency caused by hub-vertices. (1) Per-thread chunking and work-stealing. Each CN further divides its assigned vertex subset into thread-local chunks, managed by per-thread progress managers. Threads process their local chunks first and employ work-stealing upon completion, reducing contention and improving utilization. This mechanism was proved effective in Gemini [92], and DMG adopts it as the basis for intra-CN load management. (2) Runtime Re-Scheduling (RS). Previous steps assign workload only at the vertex granularity, leaving all edges of a few vertices to a single worker. As revealed in Challenge 3, this creates severe tail effects on DM: long edge lists trigger many high-latency network operations and stall overall progress. To address this issue, DMG proposes Runtime Re-Scheduling (RS), a simple yet effective runtime mechanism that decomposes hubs into smaller segments. When a worker encounters a vertex with high degree (e.g., >1024), RS splits its edge list into segments and enqueues them into a per-thread RS buffer, where segments await processing by (multiple) workers. In each thread, DMG runs multiple coroutine workers (§ 4.5.1) that prioritize processing items from this buffer before fetching new vertices, allowing RS to operate effectively within the thread and avoid synchronization overhead. Our evaluation confirms that RS effectively mitigates hub-vertex-induced stragglers and improves performance scalability as thread counts grow.

4.5

Optimizations and Discussions

4.5.1 Coroutine. Coroutines are widely used in RDMA-based systems to hide the latency of RDMA operations [68]. We employ multiple (4 by default) coroutines per thread to execute graph processing tasks. Each coroutine yields after issuing RDMA requests and resumes execution upon receiving request completions. The asynchronous nature of coroutines overlaps computation and communication, enhancing overall performance. 4.5.2 Dual-mode Execution. Push-pull dual-mode execution is a popular optimization in graph processing systems [54, 92], aiming to balance I/O volume and contention. DMG employs either push or pull mode adaptively depending on contention severity of different algorithms. By default, it uses push mode for algorithms like breadth-first search (BFS). For high-contention algorithms such as PageRank, where every edge is accessed in each iteration and the data transfer volume is similar in both modes, DMG prefers to use pull mode. In pull mode, ValRD enables the MN to aggregate partial results produced by a compute-side worker. Currently, DMG does not perform mode selection in each iteration, but chooses a mode across iterations. The selective use

of pull mode is limited by two factors: limited experimental hardware and memory efficiency. First, on our testbed with 100 Gbps RNICs, limited network bandwidth prevents us from aggressively trading more data transferred for less contention. Fortunately, the advent of RDMA and CXL with higher bandwidth (e.g., 800 Gbps and higher [50, 67]) can enable more flexible mode switching in the future. Second, supporting dual-mode for each query requires extra auxiliary in-memory structures for bidirectional access [35]. 4.5.3 Dynamic Graphs. DMG focuses on improving the performance of graph analytics queries over static graphs, as efficient processing of static graphs on DM is already a fundamental and non-trivial problem. Supporting dynamic graphs with edge insertions and deletions [46, 55, 71] is also an important direction, but is beyond the scope of this paper. However, DMG preserves a natural path toward future dynamic support. In particular, DMG’s data layout and update-propagation mechanisms are amenable to graph updates. For edge insertions, the in-place index scheme provides a natural buffer for newly added edges on low-degree vertices. For vertices with out-of-place edge lists, a temporary out-of-place list can be maintained and periodically merged back. Edge deletions can be supported by marking removed entries with a tombstone value. Notably, newly inserted edges that have not been incorporated into partitioned segments can still be correctly handled with low overhead by using ValRD for uncached update propagation. 4.5.4 When It Comes to CXL. Although this paper focuses on RDMA-based DM due to the limited availability of CXL devices, the proposed techniques are compatible and remain beneficial for CXL-based DM [23, 79, 88, 94]. For compatibility, most of DMG’s memory accesses rely on one-sided verbs, which are also supported by CXL devices. And the ValRD can also be pulled and executed by corresponding CN via coarse-grained sequential memory accesses. For effectiveness, first, the designs for reducing fine-grained accesses and hiding latency (§ 4.2 and § 4.3) naturally carry over to CXL, as latency gaps between local and remote memory accesses persist on DM, and peak CXL memory bandwidth still requires accessing at sufficiently large granularity [69]. Second, our fast and effective workload manager (§ 4.4) can benefit all multi-server graph processing systems, including those built on CXL-based DM.

5 Evaluation 5.1 Experimental Setup Testbed. We conduct experiments on 8 physical machines on the Utah cluster of CloudLab [11]. Each machine is equipped with a 24-core EPYC 7402P CPU, 128GB DRAM, PCIe v4.0 NVMe SSD, and a 100Gbps Mellanox ConnectX-5 NIC. The machines are interconnected via a 100Gbps switch. All machines run Ubuntu 22.04 with Linux kernel version 5.15.0. Each physical machine is configured to simulate either a CN or a MN. The memory pool consists of 4 MNs, each with 128 GB of DRAM. Each MN runs two threads for RPC serving and selective offloading, respectively, both of which have low CPU usage. Unless specified, each CN uses 16 threads pinned to physical cores and up to 2 GB of DRAM. Hugepages are applied to reduce address translation cache misses in RDMA NICs. Datasets and Workloads. We use four billion-scale graphs, listed in Table 3, for evaluation, including twitter-2010 (TW) as a

Yizou Chen, Tsun-Yu Yang, Zhisheng Hu, Baotong Lu, and Ming-Chang Yang

99x

179x

Number of CN (a) BFS

DMG-Base

21 20

114x

153x

223x

DMG

320x

Number of CN (b) CC

Comp. Time (s)

24 23 22 21 1

Number of CN (a) BFS

3 4 2 1

Number of CN (b) CC

Number of CN (c) PR

2 4 2 1

Number of CN (c) PR

8 6 4 2 0

2 1e3

5.1x

DMG-1CN 1

4.0x 9.2x

1 14.6x

(a) TW

DMG-2CN

11.0x

7.4x 12.6x

(b) UK

18.9x

2 1 0

10x

Number of CN (a) BFS

16x

DMG 16x

25 24

210

27 1

Number of CN (b) CC

26 1

Number of CN (c) PR

Figure 17: Computation time on rmat-29. 29 29 FAM-Graph DMG-Base Fail to Run 28 11x 28 11x 7 2 27 26

28 27 26 25 24 1

Number of CN (a) BFS

23x

5 4 2 1

Number of CN (b) CC

6 4 2 1

DMG 27x

Number of CN (c) PR

pattern. We also compare DMG with Gemini [92], a state-of-theart distributed graph processing system designed for monolithic servers, in § 5.3.

4 1e3

5.9x

DMG-Base

Figure 18: Computation time on clueweb12.

DMG-4CN

1e4

Out-of-MN-Memory

Per-CN Cache Usage (MiB)

FAM-Graph

12x

27 26

9.1x

Figure 16: Computation time on uk-2007-05.

1e2

FAM-Graph

26 24

Figure 15: Computation time on twitter-2010. 26 26 FAM-Graph DMG-Base DMG 25 25 24 24 23

Comp. Time (s)

FAM-Graph

Comp. Time (s)

1.9x 3.3x

5.2 (d) CW

Figure 19: Cache demands in each CN. social network graph, rmat-29 (R29) as a synthetic graph generated by R-MAT [5] with default parameters, uk-2007-05 (UK) and clueweb12 (CW) [3] as web crawler graphs. We evaluate three representative graph processing workloads: breadth-first search (BFS), connected components (CC), and PageRank (PR). BFS starts from non-isolated vertices. PR runs for 10 iterations with all vertices activated to obtain stable results. Table 3: Graph datasets used in evaluation. Graph

|𝑉 |

|𝐸|

Type

twitter-2010 (TW) uk-2007-05 (UK) rmat-29 (R29) clueweb12 (CW)

42 M 106 M 537 M 978 M

1.47 B 3.7 B 8.6 B 42.6 B

social network web synthetic web

Implementation and Comparisons. We implement DMG in about 11K lines of C++ code, and it will be open-sourced. We evaluate DMG primarily against FAM-Graph [83], a state-of-the-art graph processing system on disaggregated memory, and against DMG-Base, a baseline that preserves the same system architecture and compute-side cache usage but disables all our proposed designs. We omit comparisons with Fargraph [61] for brevity, since it adopts a similar impractical system architecture to FAM-Graph but exhibits significantly lower performance due to its coarse-grained access

Overall Comparison

This section presents an overall comparison of DMG against FAMGraph and DMG-Base. Our goal is to evaluate whether DMG can (1) avoid the unscalable architectures of prior systems, (2) eliminate their impractical cache demands, and (3) simultaneously deliver high performance on top of the scalable, cache-efficient DM architecture. Specifically, Figure 15–18 report the computation time across four datasets and three representative workloads. Figure 19 shows the corresponding per-CN cache demands, which remain stable across workloads for a given system and dataset. (1) DMG has a scalable and elastic DM architecture. DMG eliminates the rigidity of FAM-Graph in both memory and compute. On the memory side, FAM-Graph supports only one MN and thus cannot handle graphs exceeding a single MN’s capacity (e.g., clueweb12 in Figure 18). In contrast, DMG aggregates multiple MNs into a large shared memory pool, enabling support for large graphs. On the compute side, FAM-Graph runs only on a single CN, whereas DMG can operate efficiently with either a few CNs or many CNs while keeping memory-pool usage constant, thereby providing scalable, decoupled, and on-demand provisioning of compute and memory resources. (2) DMG demands limited compute-side cache. As shown in Figure 19, DMG dramatically reduces per-CN cache requirements compared to FAM-Graph. With one CN, DMG consumes just 17– 25% of FAM-Graph’s cache footprint by placing all data in the MN pool and caching only essential slices. Moreover, adding more CNs further reduces per-CN cache to 30–34%. This property offers two benefits: First, larger graphs can be supported under the same cachesize constraints by scaling out CNs. Second, the CNs’ aggregate memory remains a small fraction of the MNs’ memory, avoiding replication overhead and preserving resource disaggregation.

DMG Partitioning

200

400

DMG Reusable Preprocessing

600

800

1000

1200

101

CN/Server Num (a) twitter-2010

Gemini Mem 103 512 196

CN/Server Num (b) clueweb12

Mem Usage (GB)

Gemini OOM

102

DMG Mem 80 60 40 195 195 20 0 1 2 Gemini OOM

256

128

Mem Usage (GB)

Comp Time (s)

Gemini Comp 3 512 10

Comp Time (s)

Figure 20: Startup time (s) of DMG and Gemini for clueweb12 with 4 servers/CNs. DMG Comp

1.4

1.6

20 97.4

1.4

1.2

1.0

0.8 12

Size of Index

128 0.8

95.6

97.4

1B 2B 3/4B

10 5 0

92.6

7.4 2.6 0.0

4.4 0.0

2.6 0.0

R29

Datasets

0.0

Figure 22: Total MNs’ mem- Figure 23: Byte length ratio ory usage and BFS perfor- of segments for out-of-place mance with different index edge lists when 4 partitions size (TW, 1 CN)

102

Figure 21: Memory usage and BFS computation time of DMG and Gemini.

(3) DMG achieves high performance. With a single CN, despite requiring less compute-side cache to keep the DM architecture practical, DMG still achieves 1.76–2.71×, 0.91–1.19×, and 1.38–1.96× speedups over FAM-Graph on TW, UK, and R29 respectively. These gains stem from three designs: optimized data layout for faster graph retrieval, runtime rescheduling to mitigate tail effects, and coroutine-based asynchronous execution to overlap compute and communication. Scaling CNs further strengthens these advantages. When increasing from one to four CNs, DMG accelerates end-to-end performance by 1.47–3.13×. Compared to the baseline DMG-Base, DMG delivers improvements of up to two orders of magnitude. The large gap arises because hub-vertex tails and costly remote updates exacerbate each other in DMG-Base but are simultaneously mitigated in DMG. The only moderate case is the UK dataset, where improvements remain at 1.7–8.0×, owing to its sparse cross-partition edges and less skewed degree distribution.

5.3

Norm. Mem. Norm. Perf.

1.6

Ratio (%)

DMG Loading

Normalized BFS Perf.

DMG Gemini

Normalized Mem. Usage

DMG : A Scalable and Efficient Memory-Disaggregated Graph Processing System

Comparison with Traditional Distributed Graph Processing System

This section compares DMG, a graph processing system built on DM, with Gemini [92], a state-of-the-art distributed graph processing system designed for monolithic servers. We evaluate three aspects: startup time, computation time, and resource efficiency. To begin with, as shown in Figure 20, DMG substantially reduces graph startup time. For the billion-vertex clueweb12 graph, its startup time is only 2.8% of Gemini’s. Even when including the one-time preprocessing cost, whose results can be reused across executions, the total startup cost remains only 19.7% of Gemini’s. This improvement comes from two factors. First, DMG loads the graph directly into a unified large DM pool, stores each vertex’s adjacency list contiguously, and avoids the costly physical partitioning and per-server data-structure construction required by traditional distributed systems. Second, its preprocessing results are reusable, eliminating repeated graph partitioning across executions. After the graph is loaded, Figure 21 compares the memory usage and BFS computation time of DMG and Gemini on twitter-2010 and clueweb12. Despite accessing graph data from a remote memory

pool, DMG achieves computation time within 40% of Gemini, which primarily accesses local memory. This computation-time gap will further narrow as interconnect bandwidth continues to increase, for example, with 800 Gbps and faster networks [50, 67]. In return for this moderate computation overhead, DMG provides substantial improvements in end-to-end execution time and resource efficiency. Unlike Gemini, which reserves the full memory capacity of a fixed set of servers, DMG allocates memory on demand in proportion to the graph size. For smaller graphs such as twitter-2010, this reduces memory consumption by an order of magnitude. DMG also provisions compute resources independently of memory capacity, allowing even large graphs such as clueweb12 to run with only one or two CNs.

5.4

Factor Analysis

This section analyzes how individual designs in DMG contribute to overall performance and validates design choices. 5.4.1 The DM-friendly Graph Store. We first study the effect, parameters, and tradeoff in the DM-friendly graph store. Experiments are run on one CN to eliminate the multi-CN update effect. Index Structure. As shown in Figure 22, 32B and 64B indices deliver substantial speedups with modest memory amplification, while larger indices incur prohibitive memory overhead without proportional benefit. Figure 23 further shows that 1B suffices to store most segment lengths for various datasets under byte compression, suggesting that small indices can capture a substantial amount of segmentation information. Retrieval Efficiency. DMG’s adaptive index scheme and optimizations are designed to improve graph retrieval efficiency. Figure 24 shows that applying index/edge-list merging and batching (+OPT-IDX, +OPT-EDGE) and embedding indices (+EMBED) yield 2.48–4.74× end-to-end speedups, with each optimization contributing substantially. The one exception is PR: merging and batching of index reads provide little benefit since PR activates all vertices, resulting in naturally sequential access. 5.4.2 Adaptive Update Coordinator. We evaluate the adaptive update coordinator using 4 CNs to analyze both the impact of re-distribute and the comparison between different methods to perform update propagation. Effect of Re-Distribute (RD). Figure 25 shows the performance impact of two RD schemes. BASE performs all updates outside the cached chunk via direct fine-grained remote accesses. +RefRD enables RefRD, and +ValRD further enables both RefRD and ValRD.

4 2

2.81 2.22 1.47

BFS

+OPT-IDX

+EMBED 4.74

3.433.71 1.61

+OPT-EDGE

2.66 1.85 1 1.0

(a) twitter-2010

2.48 1.84 1.43

BFS

3.34 2.94

2.99 1.77 1

1 1.0

(b) uk-2007-05

Figure 24: Design effect of retrieval optimizations. 50 40 30 20 10 0

Normalized Perf.

44.4

22.3 6.43

BFS

7.71

BASE +RefRD +ValRD

30.9

7.28

(a) twitter-2010

4.69 1 2.21

BFS

14.2

11.2

3.62

1 1.63

(b) clueweb12

1 Core CPU Usage Rate (%)

Figure 25: Design effect of two types of RD. 60

30 44.4

40 20 0

21.8

BFS

44.1 30.2

36.2 36.2

(a) twitter-2010

Total Exec

20 0

3.86

8.67

BFS

1 0

BFS Iter. No.

50+

DR Update CO Update FC Update

8 6

CC Iter. No.

40+

PR Iter. No.

Figure 27: Per-iteration analytics of different methods to perform updates using 4 CNs on clueweb12.

Densest Iter

Normalized Perf.

BASE

Execution Time (s)

Yizou Chen, Tsun-Yu Yang, Zhisheng Hu, Baotong Lu, and Ming-Chang Yang

6 5 4 3 2 1

+47%

Threads Number (a) BFS on TW

9 7 5 3 1

BASE +Per-Thread +Re-Schedule

+41%

Threads Number (b) PR on CW

Figure 28: Design effect of DMG’s workload manager. Use 1 CN for #Threads≤16, 16 threads per CN for #Threads≥16

13.9 7.24

(b) clueweb12

0.86 0.86

Figure 26: CPU (1 core) usage in MNs for processing ValRD.

By converting costly direct remote updates into large sequential RDMA accesses and local updates, both RD schemes substantially improve overall graph processing performance. TW benefits more because it has a larger fraction of cross-partition edges. In practice, combining RefRD and ValRD yields the best performance and using only one pattern is less effective as discussed in § 4.3.1. CPU Usage for ValRD. Figure 26 reports CPU usage rate of the single core in MN that processes offloaded ValRD items. Even for TW, which has the highest ratio of edges spanning across chunks, the peak usage rate stays below 44% in the densest iteration and is even lower throughout the rest of the execution. For CW, which exhibits better data locality, the usage rate remains below 8% across the entire execution. These results confirm that, after turning finegrained RDMA operations into large sequential RDMA accesses by RD, processing ValRD items (i.e., performing update propagation) places only limited demands on the scarce CPU resources of MNs. Comparison of Update Propagation Methods. DMG includes two methods to perform update propagation. Collaborative Update (CO Update) is designed for dense iterations with limited cache, relying on RD to resolve uncached updates with low overhead. Direct Remote Update (DR Update) is used in sparse iterations by directly performing updates via remote operations. To further demonstrate the effectiveness of CO Update, which requires limited cache, we also implement another method for comparison: Fully-Cached Update (FC Update). In FC Update, each CN loads the attributes of all vertices into its local cache without considering cache size limits, performs all updates locally, and merges the locally cached attributes back into remote memory at iteration boundaries.

Figure 27 presents a per-iteration analysis of execution time under the three methods. From the results, we observe that: (1) The Collaborative Update method is efficient. Except for a few extremely dense iterations (e.g., early steps of CC or fully-active rounds of PR), CO Update achieves similar or even better performance compared to FC Update while requiring only #𝐶𝑁 times less cache. This is because the RD in collaborative update handles uncached updates with low overhead. In contrast, FC Update suffers from repeatedly loading and synchronizing full vertex attributes, which incurs substantial bandwidth and synchronization cost. (2) Adaptive use of Direct Remote Update is necessary. In many workloads (e.g., BFS or CC, which converge in about 500 iterations on clueweb12), a large number of iterations are very sparse, where direct remote updates are more efficient than caching. 5.4.3 Two-Stage Workload Manager. DMG employs a twostage workload manager: (1) coarse-grained partitioning for fast workload division, and (2) fine-grained runtime re-scheduling to mitigate long-tail effects and improve performance scalability with more threads. Fast Partitioning. Partitioning speed aligns with intuition: tinychunk-based partitioning completes in sub-seconds, while partitioning at per-vertex granularity takes tens to hundreds of seconds. The one-time preprocessing cost of generating tiny-chunk metadata is comparable to running per-vertex partitioning, meaning our approach is effective whenever partitioning is performed more than once, and not worse even if performed only once. In terms of end-to-end execution, which is the ultimate goal of a partitioning strategy, tiny-chunk and per-vertex schemes yield nearly identical BFS computation time on 4 CNs. This confirms that DMG achieves fast partitioning speed without compromising effectiveness. Scale to More Threads. Figure 28 reports normalized performance of BFS on TW and PR on CW as thread count increases from 4 to 64. BASE uses a centralized per-CN manager without hub-vertex handling. +Per-Thread introduces per-thread managers

DMG : A Scalable and Efficient Memory-Disaggregated Graph Processing System

with work stealing, while +Re-Schedule further enables runtime re-scheduling (RS) for hub vertices (full DMG design). With RS, performance improves by 47% and 41% at 64 threads, respectively. Per-thread management alone does not outperform BASE for BFS on TW, since the small, sparse graph makes per-thread management overhead outweigh its benefits.

Related Work

Large-scale Graph Processing. Traditional graph systems handle large graphs in two ways. Out-of-core systems [6, 22, 28, 34, 65, 74– 76, 93] store graphs on storage devices to exploit their large capacity, but are limited by I/O bandwidth and single-machine compute power. Distributed systems [7, 9, 10, 15, 92] partition graphs across monolithic servers so that each shard fits in memory, but they lack elastic resource management. FaaSGraph [35] enables graph processing on serverless platforms. Yet, it allocates resources with a fixed CPU/memory ratio, and forces large graphs to span many containers due to the limited capacity in each container. This fragmentation amplifies memory and communication overhead and yields performance inferior to DMG. Resource Disaggregation. DM has been extensively explored across various layers, including hardware [16, 30, 32, 43], operating systems [2, 17, 51, 60], user-level libraries [48, 59, 64, 72, 91], and applications [38, 52, 80, 87]. General resource disaggregation includes storage disaggregation as well [20, 47, 84]. DMG is designed for processing graph-structured data on DM and can be deployed on diverse infrastructures and leverage low-level optimizations.

Conclusion

This paper presents DMG, a graph processing system on DM. DMG addresses key challenges in achieving high performance on a practical DM architecture by a DM-friendly graph store for efficient graph placement and retrieval, an adaptive update coordinator for handling complex update propagation, and a two-stage workload manager for fast and effective load balancing. Compared to the stateof-the-art graph processing system on DM, DMG delivers superior system scalability, cache efficiency, and high performance.

References [1] [n. d.]. perftest: Infiniband Verbs Performance Tests. https://github.com/linuxrdma/perftest. https://github.com/linux-rdma/perftest [2] Emmanuel Amaro, Christopher Branner-Augmon, Zhihong Luo, Amy Ousterhout, Marcos K. Aguilera, Aurojit Panda, Sylvia Ratnasamy, and Scott Shenker. 2020. Can far memory improve job throughput?. In Proceedings of the Fifteenth European Conference on Computer Systems (Heraklion, Greece) (EuroSys ’20). Association for Computing Machinery, New York, NY, USA, Article 14, 16 pages. [3] Paolo Boldi and Sebastiano Vigna. 2004. The WebGraph Framework I: Compression Techniques. In Proc. of the Thirteenth International World Wide Web Conference (WWW 2004). ACM Press, Manhattan, USA, 595–601. [4] Irina Calciu, M. Talha Imran, Ivan Puddu, Sanidhya Kashyap, Hasan Al Maruf, Onur Mutlu, and Aasheesh Kolli. 2021. Rethinking software runtimes for disaggregated memory. In Proceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (Virtual, USA) (ASPLOS ’21). Association for Computing Machinery, New York, NY, USA, 79–92. [5] Deepayan Chakrabarti, Yiping Zhan, and Christos Faloutsos. [n. d.]. R-MAT: A Recursive Model for Graph Mining. 442–446. arXiv:https://epubs.siam.org/doi/pdf/10.1137/1.9781611972740.43 doi:10.1137/1.9781611972740.43 [6] Dechuang Chen, Sibo Wang, and Qintian Guo. 2025. ACGraph: An Efficient Asynchronous Out-of-Core Graph Processing Framework. Proc. ACM Manag. Data 3, 6, Article 290 (Dec. 2025), 26 pages. doi:10.1145/3769755

[7] Rong Chen, Jiaxin Shi, Yanzhe Chen, and Haibo Chen. 2015. PowerLyra: differentiated graph computation and partitioning on skewed graphs. In Proceedings of the Tenth European Conference on Computer Systems (Bordeaux, France) (EuroSys ’15). New York, NY, USA, Article 1, 15 pages. doi:10.1145/2741948.2741970 [8] Zheng Chen, Feng Zhang, JiaWei Guan, Jidong Zhai, Xipeng Shen, Huanchen Zhang, Wentong Shu, and Xiaoyong Du. 2023. CompressGraph: Efficient Parallel Graph Analytics with Rule-Based Compression. Proc. ACM Manag. Data 1, 1, Article 4 (May 2023), 31 pages. [9] Pengjie Cui, Haotian Liu, Dong Jiang, Bo Tang, and Ye Yuan. 2025. Nezha: An Efficient Distributed Graph Processing System on Heterogeneous Hardware. Proc. ACM Manag. Data 3, 1, Article 57 (Feb. 2025), 27 pages. doi:10.1145/3709707 [10] Roshan Dathathri, Gurbinder Gill, Loc Hoang, Hoang-Vu Dang, Alex Brooks, Nikoli Dryden, Marc Snir, and Keshav Pingali. 2018. Gluon: A communicationoptimizing substrate for distributed heterogeneous graph analytics. In Proceedings of the 39th ACM SIGPLAN conference on programming language design and implementation. 752–768. [11] Dmitry Duplyakin, Robert Ricci, Aleksander Maricq, Gary Wong, Jonathon Duerig, Eric Eide, Leigh Stoller, Mike Hibler, David Johnson, Kirk Webb, Aditya Akella, Kuangching Wang, Glenn Ricart, Larry Landweber, Chip Elliott, Michael Zink, Emmanuel Cecchet, Snigdhaswin Kar, and Prabodh Mishra. 2019. The Design and Operation of CloudLab. In 2019 USENIX Annual Technical Conference (USENIX ATC 19). USENIX Association, Renton, WA, 1–14. https://www.usenix. org/conference/atc19/presentation/duplyakin [12] Darren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, and Jonathan Larson. 2024. From local to global: A graph rag approach to query-focused summarization. arXiv preprint arXiv:2404.16130 (2024). [13] Orri Erling, Alex Averbuch, Josep Larriba-Pey, Hassan Chafi, Andrey Gubichev, Arnau Prat, Minh-Duc Pham, and Peter Boncz. 2015. The LDBC Social Network Benchmark: Interactive Workload. In Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data (Melbourne, Victoria, Australia) (SIGMOD ’15). Association for Computing Machinery, New York, NY, USA, 619–630. doi:10.1145/2723372.2742786 [14] Gurbinder Gill, Roshan Dathathri, Loc Hoang, and Keshav Pingali. 2018. A study of partitioning policies for graph analytics on large-scale distributed platforms. Proceedings of the VLDB Endowment 12, 4 (2018), 321–334. [15] Joseph E. Gonzalez, Yucheng Low, Haijie Gu, Danny Bickson, and Carlos Guestrin. 2012. PowerGraph: Distributed Graph-Parallel Computation on Natural Graphs. In 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI 12). Hollywood, CA, 17–30. [16] Donghyun Gouk, Miryeong Kwon, Hanyeoreum Bae, Sangwon Lee, and Myoungsoo Jung. 2023. Memory Pooling With CXL. IEEE Micro 43, 2 (2023), 48–57. [17] Juncheng Gu, Youngmoon Lee, Yiwen Zhang, Mosharaf Chowdhury, and Kang G Shin. 2017. Efficient memory disaggregation with infiniswap. In 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI 17). 649–667. [18] Hao Guo and Youyou Lu. 2025. Achieving Low-Latency Graph-Based Vector Search via Aligning Best-First Search Algorithm with SSD. In 19th USENIX Symposium on Operating Systems Design and Implementation (OSDI 25). USENIX Association, Boston, MA, 171–186. [19] Jing Guo, Zihao Chang, Sa Wang, Haiyang Ding, Yihui Feng, Liang Mao, and Yungang Bao. 2019. Who limits the resource efficiency of my datacenter: an analysis of Alibaba datacenter traces. In Proceedings of the International Symposium on Quality of Service (Phoenix, Arizona) (IWQoS ’19). Association for Computing Machinery, New York, NY, USA, Article 39, 10 pages. [20] Zhihan Guo, Xinyu Zeng, Kan Wu, Wuh-Chwen Hwang, Ziwei Ren, Xiangyao Yu, Mahesh Balakrishnan, and Philip A. Bernstein. 2022. Cornus: atomic commit for a cloud DBMS with storage disaggregation. Proc. VLDB Endow. 16, 2 (Oct. 2022), 379–392. [21] Zhisheng Hu, Pengfei Zuo, Yizou Chen, Chao Wang, Junliang Hu, and MingChang Yang. 2024. Aceso: Achieving Efficient Fault Tolerance in MemoryDisaggregated Key-Value Stores. In Proceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles (Austin, TX, USA) (SOSP ’24). Association for Computing Machinery, New York, NY, USA, 127–143. [22] Chengying Huan, Zhengyi Yang, Haoshen Yang, Shaonan Ma, Rong Gu, Fang Xi, Yongchao Liu, Guihai Chen, and Chen Tian. 2025. Gem: Scalable Monotonic Graph Processing Beyond Billion-Scale on a Single Machine. Proc. ACM Manag. Data 3, 6, Article 330 (Dec. 2025), 30 pages. doi:10.1145/3769795 [23] Jialiang Huang, MingXing Zhang, Teng Ma, Zheng Liu, Sixing Lin, Kang Chen, Jinlei Jiang, Xia Liao, Yingdi Shan, Ning Zhang, Mengting Lu, Tao Ma, Haifeng Gong, and YongWei Wu. 2024. TrEnv: Transparently Share Serverless Execution Environments Across Different Functions and Nodes. In Proceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles (Austin, TX, USA) (SOSP ’24). Association for Computing Machinery, New York, NY, USA, 421–437. [24] Suhas Jayaram Subramanya, Fnu Devvrit, Harsha Vardhan Simhadri, Ravishankar Krishnawamy, and Rohan Kadekodi. 2019. DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node. In Advances in Neural Information Processing Systems, H. Wallach, H. Larochelle, A. Beygelzimer, F. d'Alché-Buc, E. Fox, and R. Garnett (Eds.), Vol. 32. Curran Associates, Inc.

Yizou Chen, Tsun-Yu Yang, Zhisheng Hu, Baotong Lu, and Ming-Chang Yang

[25] Anuj Kalia, Michael Kaminsky, and David G Andersen. 2016. Design guidelines for high performance { RDMA } systems. In 2016 USENIX Annual Technical Conference (USENIX ATC 16). 437–450. [26] Pradeep Kumar and H Howie Huang. 2020. Graphone: A data store for real-time analytics on evolving graphs. ACM Transactions on Storage (TOS) 15, 4 (2020), 1–40. [27] Haewoon Kwak, Changhyun Lee, Hosung Park, and Sue Moon. 2010. What is Twitter, a social network or a news media?. In Proceedings of the 19th international conference on World wide web. 591–600. [28] Aapo Kyrola, Guy Blelloch, and Carlos Guestrin. 2012. GraphChi: Large-Scale Graph Computation on Just a PC. In 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI 12). Hollywood, CA, 31–46. [29] Sekwon Lee, Soujanya Ponnapalli, Sharad Singhal, Marcos K. Aguilera, Kimberly Keeton, and Vijay Chidambaram. 2022. DINOMO: An Elastic, Scalable, HighPerformance Key-Value Store for Disaggregated Persistent Memory. Proc. VLDB Endow. 15, 13 (Sept. 2022), 4023–4037. doi:10.14778/3565838.3565854 [30] Seung-Seob Lee, Yanpeng Yu, Yupeng Tang, Anurag Khandelwal, Lin Zhong, and Abhishek Bhattacharjee. 2021. MIND: In-Network Memory Management for Disaggregated Data Centers. In SOSP ’21: ACM SIGOPS 28th Symposium on Operating Systems Principles, Koblenz, Germany. ACM, 488–504. [31] Guoliang Li, Wengang Tian, Jinyu Zhang, Ronen Grosman, Zongchao Liu, and Sihao Li. 2024. GaussDB: A Cloud-Native Multi-Primary Database with Compute-Memory-Storage Disaggregation. Proc. VLDB Endow. 17, 12 (Aug. 2024), 3786–3798. doi:10.14778/3685800.3685806 [32] Huaicheng Li, Daniel S. Berger, Lisa Hsu, Daniel Ernst, Pantea Zardoshti, Stanko Novakovic, Monish Shah, Samir Rajadnya, Scott Lee, Ishwar Agarwal, Mark D. Hill, Marcus Fontoura, and Ricardo Bianchini. 2023. Pond: CXL-Based Memory Pooling Systems for Cloud Platforms. In Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2, ASPLOS 2023, Vancouver, BC, Canada. ACM, 574–587. [33] Compute Express Link. 2023. Compute express link: The breakthrough cpu-todevice interconnect. https://www.computeexpresslink.org/. [34] Hang Liu and H. Howie Huang. 2017. Graphene: Fine-Grained IO Management for Graph Computing. In 15th USENIX Conference on File and Storage Technologies (FAST 17). Santa Clara, CA, 285–300. [35] Yushi Liu, Shixuan Sun, Zijun Li, Quan Chen, Sen Gao, Bingsheng He, Chao Li, and Minyi Guo. 2024. FaaSGraph: Enabling Scalable, Efficient, and Cost-Effective Graph Processing with Serverless Computing. In Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2 (La Jolla, CA, USA) (ASPLOS ’24). Association for Computing Machinery, New York, NY, USA, 385–400. doi:10.1145/3620665. 3640361 [36] Baotong Lu, Kaisong Huang, Chieh-Jan Mike Liang, Tianzheng Wang, and Eric Lo. 2024. DEX: Scalable Range Indexing on Disaggregated Memory. Proc. VLDB Endow. 17, 10 (Aug. 2024), 2603–2616. [37] Chengzhi Lu, Kejiang Ye, Guoyao Xu, Cheng-Zhong Xu, and Tongxin Bai. 2017. Imbalance in the cloud: An analysis on Alibaba cluster trace. In 2017 IEEE International Conference on Big Data (Big Data). 2884–2892. doi:10.1109/BigData.2017. 8258257 [38] Haodi Lu, Haikun Liu, Yujian Zhang, Zhuohui Duan, Xiaofei Liao, Hai Jin, and Yu Zhang. 2025. Fast distributed transactions for RDMA-based disaggregated memory. In Proceedings of the 2025 USENIX Conference on Usenix Annual Technical Conference (Boston, MA, USA) (USENIX ATC ’25). USENIX Association, USA, Article 55, 16 pages. [39] Xuchuan Luo, Jiacheng Shen, Pengfei Zuo, Xin Wang, Michael R. Lyu, and Yangfan Zhou. 2024. CHIME: A Cache-Efficient and High-Performance Hybrid Index on Disaggregated Memory. In Proceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles (Austin, TX, USA) (SOSP ’24). Association for Computing Machinery, New York, NY, USA, 110–126. [40] Xuchuan Luo, Pengfei Zuo, Jiacheng Shen, Jiazhen Gu, Xin Wang, Michael R. Lyu, and Yangfan Zhou. 2023. SMART: A High-Performance Adaptive Radix Tree for Disaggregated Memory. In 17th USENIX Symposium on Operating Systems Design and Implementation (OSDI 23). Boston, MA. [41] Peter Macko, Virendra J Marathe, Daniel W Margo, and Margo I Seltzer. 2015. Llama: Efficient graph analytics using large multiversioned arrays. In 2015 IEEE 31st International Conference on Data Engineering. IEEE, 363–374. [42] Yu A Malkov and Dmitry A Yashunin. 2018. Efficient and robust approximate nearest neighbor search using hierarchical navigable small world graphs. IEEE transactions on pattern analysis and machine intelligence 42, 4 (2018), 824–836. [43] Hasan Al Maruf, Hao Wang, Abhishek Dhanotia, Johannes Weiner, Niket Agarwal, Pallab Bhattacharya, Chris Petersen, Mosharaf Chowdhury, Shobhit O. Kanaujia, and Prakash Chauhan. 2023. TPP: Transparent Page Placement for CXL-Enabled Tiered-Memory. In Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 3, ASPLOS 2023, Vancouver, BC, Canada. ACM, 742–755. [44] Donald Nguyen, Andrew Lenharth, and Keshav Pingali. 2013. A lightweight infrastructure for graph analytics. In Proceedings of the twenty-fourth ACM symposium on operating systems principles. 456–471.

[45] Vlad Nitu, Boris Teabe, Alain Tchana, Canturk Isci, and Daniel Hagimont. 2018. Welcome to zombieland: practical and energy-efficient memory disaggregation in a datacenter. In Proceedings of the Thirteenth EuroSys Conference (Porto, Portugal) (EuroSys ’18). Association for Computing Machinery, New York, NY, USA, Article 16, 12 pages. [46] Prashant Pandey, Brian Wheatman, Helen Xu, and Aydin Buluc. 2021. Terrace: A hierarchical graph container for skewed dynamic graphs. In Proceedings of the 2021 international conference on management of data. 1372–1385. [47] Xi Pang and Jianguo Wang. 2024. Understanding the Performance Implications of the Design Principles in Storage-Disaggregated Databases. Proc. ACM Manag. Data 2, 3, Article 180 (May 2024), 26 pages. doi:10.1145/3654983 [48] Feng Ren, Mingxing Zhang, Kang Chen, Huaxia Xia, Zuoning Chen, and Yongwei Wu. 2024. Scaling Up Memory Disaggregated Applications with SMART. In Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 1 (La Jolla, CA, USA) (ASPLOS ’24). Association for Computing Machinery, New York, NY, USA, 351–367. [49] Jie Ren, Minjia Zhang, and Dong Li. 2020. HM-ANN: efficient billion-point nearest neighbor search on heterogeneous memory. In Proceedings of the 34th International Conference on Neural Information Processing Systems (Vancouver, BC, Canada) (NIPS ’20). Curran Associates Inc., Red Hook, NY, USA, Article 895, 13 pages. [50] André Ryser, Alberto Lerner, Alex Forencich, and Philippe Cudré-Mauroux. 2022. D-RDMA: Bringing Zero-Copy RDMA to Database Systems. In 12th Conference on Innovative Data Systems Research, CIDR 2022, Chaminade, CA, USA, January 9-12, 2022. www.cidrdb.org. https://www.cidrdb.org/cidr2022/papers/p77-ryser.pdf [51] Yizhou Shan, Yutong Huang, Yilun Chen, and Yiying Zhang. 2018. LegoOS: A Disseminated, Distributed OS for Hardware Resource Disaggregation. In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18). Carlsbad, CA. [52] Jiacheng Shen, Pengfei Zuo, Xuchuan Luo, Yuxin Su, Jiazhen Gu, Hao Feng, Yangfan Zhou, and Michael R Lyu. 2023. Ditto: An elastic and adaptive memorydisaggregated caching system. In Proceedings of the 29th Symposium on Operating Systems Principles. 675–691. [53] Jiacheng Shen, Pengfei Zuo, Xuchuan Luo, Tianyi Yang, Yuxin Su, Yangfan Zhou, and Michael R. Lyu. 2023. FUSEE: A Fully Memory-Disaggregated Key-Value Store. In 21st USENIX Conference on File and Storage Technologies (FAST 23). Santa Clara, CA. [54] Julian Shun and Guy E. Blelloch. 2013. Ligra: a lightweight graph processing framework for shared memory. In Proceedings of the 18th ACM SIGPLAN symposium on Principles and practice of parallel programming. New York, NY, USA, 135–146. [55] Jixian Su, Chiyu Hao, Shixuan Sun, Hao Zhang, Sen Gao, Jiaxin Jiang, Yao Chen, Chenyi Zhang, Bingsheng He, and Minyi Guo. 2025. Revisiting the Design of In-Memory Dynamic Graph Storage. Proc. ACM Manag. Data 3, 1, Article 70 (Feb. 2025), 27 pages. doi:10.1145/3709720 [56] John Thorpe, Yifan Qiao, Jonathan Eyolfson, Shen Teng, Guanzhou Hu, Zhihao Jia, Jinliang Wei, Keval Vora, Ravi Netravali, Miryung Kim, and Guoqing Harry Xu. 2021. Dorylus: Affordable, Scalable, and Accurate GNN Training with Distributed CPU Servers and Serverless Threads. In 15th USENIX Symposium on Operating Systems Design and Implementation (OSDI 21). USENIX Association, 495–514. [57] Muhammad Tirmazi, Adam Barker, Nan Deng, Md E. Haque, Zhijing Gene Qin, Steven Hand, Mor Harchol-Balter, and John Wilkes. 2020. Borg: the next generation. In Proceedings of the Fifteenth European Conference on Computer Systems (Heraklion, Greece) (EuroSys ’20). Association for Computing Machinery, New York, NY, USA, Article 30, 14 pages. [58] Infiniband trade association. 2023. InfiniBand. https://www.infinibandta.org/. [59] Chenxi Wang, Haoran Ma, Shi Liu, Yifan Qiao, Jonathan Eyolfson, Christian Navasca, Shan Lu, and Guoqing Harry Xu. 2022. MemLiner: Lining up Tracing and Application for a Far-Memory-Friendly Runtime. In 16th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2022, Carlsbad, CA, USA. USENIX Association, 35–53. [60] Chenxi Wang, Yifan Qiao, Haoran Ma, Shi Liu, Wenguang Chen, Ravi Netravali, Miryung Kim, and Guoqing Harry Xu. 2023. Canvas: Isolated and Adaptive Swapping for Multi-Applications on Remote Memory. In 20th USENIX Symposium on Networked Systems Design and Implementation, NSDI 2023, Boston, MA. USENIX Association, 161–179. [61] Jing Wang, Chao Li, Taolei Wang, Lu Zhang, Pengyu Wang, Junyi Mei, and Minyi Guo. 2022. Excavating the potential of graph workload on rdma-based far memory architecture. In 2022 IEEE International Parallel and Distributed Processing Symposium (IPDPS). 1029–1039. [62] Qing Wang, Youyou Lu, and Jiwu Shu. 2022. Sherman: A Write-Optimized Distributed B+Tree Index on Disaggregated Memory. In Proceedings of the 2022 International Conference on Management of Data (Philadelphia, PA, USA) (SIGMOD ’22). New York, NY, USA. [63] Ruihong Wang, Chuqing Gao, Jianguo Wang, Prishita Kadam, M. TamerÖzsu, and Walid G. Aref. 2024. Optimizing LSM-based indexes for disaggregated memory.

DMG : A Scalable and Efficient Memory-Disaggregated Graph Processing System

The VLDB Journal 33, 6 (June 2024), 1813–1836. doi:10.1007/s00778-024-00863-y [64] Ruihong Wang, Jianguo Wang, and Walid G. Aref. 2025. Cache Coherence Over Disaggregated Memory. Proc. VLDB Endow. 18, 9 (May 2025), 2978–2991. doi:10.14778/3746405.3746422 [65] Rui Wang, Weixu Zong, Shuibing He, Xinyu Chen, Zhenxin Li, and Zheng Dang. 2024. Efficient Large Graph Processing with Chunk-Based Graph Representation Model. In 2024 USENIX Annual Technical Conference (USENIX ATC 24). USENIX Association, Santa Clara, CA, 1239–1255. [66] Yuke Wang, Boyuan Feng, Zheng Wang, Tong Geng, Kevin Barker, Ang Li, and Yufei Ding. 2023. MGG: Accelerating Graph Neural Networks with Fine-Grained Intra-Kernel Communication-Computation Pipelining on Multi-GPU Platforms. In 17th USENIX Symposium on Operating Systems Design and Implementation (OSDI 23). USENIX Association, Boston, MA, 779–795. [67] Zilong Wang, Xinchen Wan, Luyang Li, Yijun Sun, Peng Xie, Xin Wei, Qingsong Ning, Junxue Zhang, and Kai Chen. 2024. Fast, Scalable, and Accurate Rate Limiter for RDMA NICs. In Proceedings of the ACM SIGCOMM 2024 Conference, ACM SIGCOMM 2024, Sydney, NSW, Australia, August 4-8, 2024. ACM, 568–580. doi:10.1145/3651890.3672215 [68] Xingda Wei, Zhiyuan Dong, Rong Chen, and Haibo Chen. 2018. Deconstructing RDMA-enabled Distributed Transactions: Hybrid is Better!. In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18). USENIX Association, Carlsbad, CA, 233–251. [69] Marcel Weisgut, Daniel Ritter, Pinar Tözün, Lawrence Benson, and Tilmann Rabl. 2025. CXL Memory Performance for In-Memory Data Processing. Proc. VLDB Endow. 18, 9 (May 2025), 3119–3133. doi:10.14778/3746405.3746432 [70] Shiwen Wu, Fei Sun, Wentao Zhang, Xu Xie, and Bin Cui. 2022. Graph Neural Networks in Recommender Systems: A Survey. ACM Comput. Surv. 55, 5, Article 97 (Dec. 2022), 37 pages. [71] Haoxuan Xie, Junfeng Liu, Siqiang Luo, and Kai Wang. 2026. RadixGraph: A Fast, Space-Optimized Data Structure for Dynamic Graph Storage (Extended Version). arXiv:2601.01444 [cs.DB] https://arxiv.org/abs/2601.01444 [72] Bin Yan, Youyou Lu, Qing Wang, Minhui Xie, and Jiwu Shu. 2023. Patronus: High-Performance and Protective Remote Memory. In 21st USENIX Conference on File and Storage Technologies (FAST 23). USENIX Association, Santa Clara, CA, 315–330. https://www.usenix.org/conference/fast23/presentation/yan [73] Ke Yang, MingXing Zhang, Kang Chen, Xiaosong Ma, Yang Bai, and Yong Jiang. 2019. KnightKing: a fast distributed graph random walk engine. In Proceedings of the 27th ACM Symposium on Operating Systems Principles (Huntsville, Ontario, Canada) (SOSP ’19). Association for Computing Machinery, New York, NY, USA, 524–537. [74] Tsun-Yu Yang, Yizou Chen, Yuhong Liang, and Ming-Chang Yang. 2024. Seraph: Towards Scalable and Efficient Fully-external Graph Computation via Ondemand Processing. In 22nd USENIX Conference on File and Storage Technologies (FAST 24). Santa Clara, CA, 373–387. [75] Tsun-Yu Yang, Yizou Chen, Yuhong Liang, and Ming-Chang Yang. 2025. Leveraging On-demand Processing to Co-optimize Scalability and Efficiency for Fullyexternal Graph Computation. ACM Trans. Storage 21, 2, Article 11 (Feb. 2025), 31 pages. doi:10.1145/3701037 [76] Tsun-Yu Yang, Yi Li, Yizou Chen, Bingzhe Li, and Ming-Chang Yang. 2025. Oasis: An Out-of-core Approximate Graph System via All-Distances Sketches. In 23rd USENIX Conference on File and Storage Technologies (FAST 25). USENIX Association, Santa Clara, CA, 523–537. [77] Xinjun Yang, Yingqiang Zhang, Hao Chen, Feifei Li, Gerry Fan, Yang Kong, Bo Wang, Jing Fang, Yuhui Wang, Tao Huang, Wenpu Hu, Jim Kao, and Jianping Jiang. 2025. Unlocking the Potential of CXL for Disaggregated Memory in CloudNative Databases. In Companion of the 2025 International Conference on Management of Data (Berlin, Germany) (SIGMOD/PODS ’25). Association for Computing Machinery, New York, NY, USA, 689–702. doi:10.1145/3722212.3724460 [78] Xinjun Yang, Yingqiang Zhang, Hao Chen, Feifei Li, Bo Wang, Jing Fang, Chuan Sun, and Yuhui Wang. 2024. PolarDB-MP: A Multi-Primary CloudNative Database via Disaggregated Shared Memory. In Companion of the 2024 International Conference on Management of Data (Santiago AA, Chile) (SIGMOD ’24). Association for Computing Machinery, New York, NY, USA, 295–308. doi:10.1145/3626246.3653377 [79] Yiwei Yang, Pooneh Safayenikoo, Jiacheng Ma, Tanvir Ahmed Khan, and Andrew Quinn. 2023. CXLMemSim: A pure software simulated CXL. mem for performance characterization. arXiv preprint arXiv:2303.06153 (2023). [80] Peiqi Yin, Xiao Yan, Shiyuan Deng, Hui Li, Yifan Zhu, Xiangyu Zhi, Jingqi Mao, Ran Xu, Wenliang Zhang, and James Cheng. 2026. DistVS: Large-scale Vector Search with Compute-Memory Disaggregation. In 23rd USENIX Symposium on Networked Systems Design and Implementation (NSDI 26). USENIX Association, Renton, WA, 449–467. [81] Song Yu, Shufeng Gong, Qian Tao, Sijie Shen, Yanfeng Zhang, Wenyuan Yu, Pengxi Liu, Zhixin Zhang, Hongfu Li, Xiaojian Luo, Ge Yu, and Jingren Zhou. 2024. LSMGraph: A High-Performance Dynamic Graph Storage System with Multi-Level CSR. Proc. ACM Manag. Data 2, 6, Article 243 (Dec. 2024), 28 pages. doi:10.1145/3698818

[82] Xiangyao Yu. 2025. Disaggregation: A New Architecture for Cloud Databases. Proc. VLDB Endow. 18, 12 (Aug. 2025), 5527–5530. doi:10.14778/3750601.3760520 [83] Daniel Zahka and Ada Gavrilovska. 2022. FAM-Graph: Graph analytics on disaggregated memory. In 2022 IEEE International Parallel and Distributed Processing Symposium (IPDPS). 81–92. [84] Shaoxun Zeng, Xiaojian Liao, Hao Guo, and Youyou Lu. 2024. Volley: Accelerating Write-Read Orders in Disaggregated Storage. In Proceedings of the Nineteenth European Conference on Computer Systems (Athens, Greece) (EuroSys ’24). Association for Computing Machinery, New York, NY, USA, 657–673. [85] Hantian Zha, Teng Ma, Baotong Lu, Yuansen Wang, Dongbiao He, Yuanhui Luo, Dafang Zhang, Yunpeng Chai, Yuxing Chen, and Anqun Pan. 2025. Shard: A Scalable and Resize-Optimized Hash Index on Disaggregated Memory. Proc. VLDB Endow. 19, 4 (Dec. 2025), 684–697. doi:10.14778/3785297.3785309 [86] Chenzi Zhang, Fan Wei, Qin Liu, Zhihao Gavin Tang, and Zhenguo Li. 2017. Graph Edge Partitioning via Neighborhood Heuristic. In Proceedings of the 23rd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (Halifax, NS, Canada) (KDD ’17). Association for Computing Machinery, New York, NY, USA, 605–614. [87] Ming Zhang, Yu Hua, and Zhijun Yang. 2024. Motor: Enabling Multi-Versioning for Distributed Transactions on Disaggregated Memory. In 18th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2024, Santa Clara, CA, USA. USENIX Association, 801–819. [88] Mingxing Zhang, Teng Ma, Jinqi Hua, Zheng Liu, Kang Chen, Ning Ding, Fan Du, Jinlei Jiang, Tao Ma, and Yongwei Wu. 2023. Partial Failure Resilient Memory Management System for (CXL-based) Distributed Shared Memory. In Proceedings of the 29th Symposium on Operating Systems Principles (Koblenz, Germany) (SOSP ’23). Association for Computing Machinery, New York, NY, USA, 658–674. [89] Qizhen Zhang, Xinyi Chen, Sidharth Sankhe, Zhilei Zheng, Ke Zhong, Sebastian Angel, Ang Chen, Vincent Liu, and Boon Thau Loo. 2022. Optimizing dataintensive systems in disaggregated data centers with teleport. In Proceedings of the 2022 International Conference on Management of Data. 1345–1359. [90] Wenqian Zhang, Zhengyi Yang, Dong Wen, Wentao Li, Wenjie Zhang, and Xuemin Lin. 2025. Accelerating Core Decomposition in Billion-Scale Hypergraphs. Proc. ACM Manag. Data 3, 1, Article 6 (Feb. 2025), 27 pages. doi:10.1145/3709656 [91] Yang Zhou, Hassan M. G. Wassel, Sihang Liu, Jiaqi Gao, James Mickens, Minlan Yu, Chris Kennelly, Paul Turner, David E. Culler, Henry M. Levy, and Amin Vahdat. 2022. Carbink: Fault-Tolerant Far Memory. In 16th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2022, Carlsbad, CA, USA. USENIX Association, 55–71. [92] Xiaowei Zhu, Wenguang Chen, Weimin Zheng, and Xiaosong Ma. 2016. Gemini: A { Computation-Centric } distributed graph processing system. In 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI 16). 301–316. [93] Xiaowei Zhu, Wentao Han, and Wenguang Chen. 2015. GridGraph: Large-Scale Graph Processing on a Single Machine Using 2-Level Hierarchical Partitioning. In 2015 USENIX Annual Technical Conference (USENIX ATC 15). Santa Clara, CA, 375–386. [94] Zhiting Zhu, Newton Ni, Yibo Huang, Yan Sun, Zhipeng Jia, Nam Sung Kim, and Emmett Witchel. 2024. Lupin: Tolerating Partial Failures in a CXL Pod. In Proceedings of the 2nd Workshop on Disruptive Memory Systems (Austin, TX, USA) (DIMES ’24). Association for Computing Machinery, New York, NY, USA, 41–50. [95] Tobias Ziegler, Sumukha Tumkur Vani, Carsten Binnig, Rodrigo Fonseca, and Tim Kraska. 2019. Designing Distributed Tree-based Index Structures for Fast RDMA-capable Networks. In Proceedings of the 2019 International Conference on Management of Data (Amsterdam, Netherlands) (SIGMOD ’19). Association for Computing Machinery, New York, NY, USA, 741–758.

Record · ID 394373 · SHA-256 6bff81dfbb16971e
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.