{"id":"1cd5bf4b-2963-4655-834f-3dd9f53c9946","arxiv_id":"2607.20881","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"DMG makes graph processing on disaggregated memory practical by combining a DM-friendly graph store, adaptive update propagation, and fast two-stage load balancing, scaling to multiple compute/memory nodes with small caches.","lead":"This paper presents DMG, a graph-processing system designed for memory-disaggregated data centers, where compute and memory live in separate pools. It reports that DMG scales to multiple compute and memory nodes while using only small compute-side caches, and outperforms prior disaggregated-memory graph systems by up to 4.9x in tests.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"MN CPU assumption not stress-tested: ValRD offload may bottleneck on real 1–2 core memory nodes, threatening scalability claim.","rationale":"The reader's weakest assumption identifies exactly the same load-bearing point: MN-side compute is under-provisioned in the testbed relative to real DM memory nodes. The paper's own numbers (Figure 26) show up to 44% utilization on a single EPYC core for ValRD; scaling to a weak core could make the MN the bottleneck, and the two threads for RPC/offloading add further contention. This is a correct and important concern, not a fabricated one. No internal inconsistency or fabrication was found; the concern is about external validity. Therefore the CONDITIONAL verdict is appropriate, pending the MN-CPU stress test and artifact release. If the test passes (MN CPU is not saturated), the central claim is substantially supported; if it fails, the performance and scalability numbers would need to be reinterpreted.","tokens_in":27604,"tokens_out":4335,"duration_ms":42583,"concrete_test":"Restrict MNs to one or two low-frequency physical cores (e.g., using cpuset + cpufreq) and re-run BFS/CC/PR on TW and CW with 4 CNs (Figures 15–18, 25–27). Measure per-iteration time and MN CPU utilization. If MN CPU utilization exceeds ~80% in any iteration, or end-to-end time increases by more than 30% relative to the 24-core MN configuration, the scalability claim relies on unrealistic MN CPU provisioning.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central scalability/cache-efficiency claim depends on MNs executing offloaded update work (ValRD) and RPC serving without becoming the bottleneck. The testbed simulates each MN with a 24-core EPYC 7402P CPU (§5.1), whereas real DM memory nodes are assumed to have only 1–2 weak cores (§2.2). §5.4.2 reports peak CPU usage of 44% on a single core for ValRD on TW (Figure 26), but that is one EPYC core; on a realistic MN core (lower frequency, simpler pipeline) utilization could approach saturation, and the MN also runs RPC-serving threads. If MN CPU becomes the limiting resource, adding CNs will not scale performance proportionally, and the claimed 4.9× speedup / 18.9× cache reduction are not representative of actual DM deployments. The paper's statement that 'a single MN thread can handle offloaded ValRD items with limited CPU usage' (§4.3.1) is only validated on the 24-core testbed. This assumption is load-bearing because the architecture deliberately moves update logic to MNs (pass-by-value) to avoid fine-grained remote atomics; if MN CPU is scarce, the design must fall back to CN-side processing and incur the remote-update costs it aims to avoid.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"DMG proposes a graph processing system for memory-disaggregated (DM) architectures. It contributes three main designs: (i) a DM-friendly graph store that embeds low-degree edge lists in an enlarged index and applies merged/batched RDMA retrieval; (ii) an adaptive update coordinator that selects between collaborative update (with pass-by-reference and pass-by-value re-distribution) and direct remote update depending on update density; and (iii) a two-stage workload manager using coarse-grained tiny-chunk partitioning plus runtime hub re-scheduling. The paper claims this is the first practical multi-CN/multi-MN graph processing system on DM, achieving up to 4.9× speedup over FAM-Graph, up to 18.9× reduction in compute-side cache demand, and computation time within 40% of the local-memory distributed system Gemini. The evaluation includes internal ablations over the proposed components and comparisons with FAM-Graph, DMG-Base, and Gemini on four billion-scale graphs.","tokens_in":27873,"tokens_out":10468,"duration_ms":111309,"significance":"If the claims hold, this is a substantial contribution to the DM systems literature. The paper identifies an important practical gap in existing DM graph systems (single CN/MN and large compute-side caches) and proposes concrete mechanisms to address it. A particular strength is the internal ablation in §5.4: separating the effects of index embedding, retrieval optimizations, the two re-distribution modes, and runtime re-scheduling gives good evidence that the design choices, not just the overall architecture, drive the reported gains. The cache-efficiency result (orders of magnitude below FAM-Graph) and the startup-time comparison with Gemini are also compelling. However, the central scalability and performance claims rest on assumptions about memory-node CPU availability and on a fixed 4-MN testbed; these are not yet fully stress-tested, and the absence of repeated-run statistics makes some quantitative claims difficult to assess.","major_comments":[{"comment":"MN CPU model: The system model in §2.2 assumes MNs have weak computation power (e.g., 1–2 CPU cores), but the testbed uses 24-core EPYC 7402P MNs (only two threads active). The ValRD mechanism (§4.3.1) is load-bearing: Fig. 25 shows +ValRD provides a large improvement over +RefRD. However, the MN CPU validation in Fig. 26 reports at most 44% usage of one EPYC core for TW; this does not establish that the same offload is sustainable on a real 1–2 core, lower-performance MN that also runs RPC-serving threads. I recommend adding an experiment that pins MN threads to one or two cores, or otherwise models weak MNs, and reports end-to-end performance and ValRD CPU/throughput under that constraint. If ValRD saturates, the fallback path could erode the reported speedups.","section":"§5.1/§5.4.2"},{"comment":"Memory-side scalability is not directly demonstrated. The abstract claims elastic scaling of both compute and memory, but all scaling experiments vary only the number of CNs (1, 2, 4) with a fixed 4-MN pool. I could not find an experiment that varies the number of MNs, or that increases graph size while scaling MNs. The clueweb12 result shows DMG can use a 4-MN pool where FAM-Graph cannot, but not that adding MNs elastically accommodates ever-increasing graphs. Please add a memory-scaling experiment (e.g., 1→4 MNs with fixed CN count, or a graph that grows with MN count) or temper the claim.","section":"§5.2/§5.1"},{"comment":"All reported numbers appear to be from single executions, with no error bars or variance information. This matters for the quantitative headline claims (4.9× speedup, 18.9× cache reduction) and for small differences such as the UK 0.91–1.19× speedup range in §5.2. I request repeated runs (at least 3–5 per configuration) with confidence intervals, or at minimum a statement of run-to-run variability, for the key figures (Figs. 15–19, 24, 25, 28).","section":"§5 (general methodology)"},{"comment":"Several design thresholds—32B index entry size, in-place degree ≤7, RS hub threshold >1024, 4 coroutines per thread, 1024 tiny-chunks—appear to be chosen based on the four benchmark graphs, and the index-size sweep (Fig. 22) is shown only for TW. Since the main comparisons use the same datasets, it is unclear whether these values are overfit to the testbed. Please add a sensitivity analysis for the most impactful thresholds across datasets and at least one other hardware configuration, or give an explicit argument that the thresholds are hardware- and dataset-independent.","section":"§4.2.1/§5.4.1"}],"minor_comments":[{"comment":"The captions do not define what the annotated ratios (e.g., '99x', '179x') refer to. Clarify whether they are speedups of DMG over DMG-Base or over FAM-Graph, and how FAM-Graph is plotted at 2 and 4 CNs when it supports only one CN.","section":"Figs. 15–18"},{"comment":"Please define 'per-CN cache usage' precisely (maximum RSS, allocated cache size, or measured working set) and state whether the FAM-Graph bar is for one CN only. This would help readers interpret the 18.9× claim.","section":"Fig. 19"},{"comment":"The statement that DMG achieves computation time 'within 40% of Gemini' is ambiguous: does it mean 40% slower, or 40% of Gemini's time? The text later says 'moderate computation overhead,' suggesting the former. Please rephrase.","section":"§5.3"},{"comment":"There are small text issues: 'toDM-friendly' in the abstract and 'ontwitter-2010' in §5.3 are missing spaces. Also, the paper promises open-source code; please include the repository or artifact link at the final version.","section":"Abstract and §5.3"}],"recommendation":"major_revision","confidential_remarks":"The paper is a strong candidate after revision. The two load-bearing gaps are (1) the MN CPU assumption behind ValRD and (2) the absence of MN-count scaling experiments. The single-run evaluation and the dataset-specific threshold choices are secondary but should be addressed to make the quantitative claims reliable. The internal ablation is a genuine strength and should be preserved."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"DMG is a real step forward for graph processing on disaggregated memory. It is the first system I know of that actually scales to multiple compute and memory nodes while keeping CN caches in the 1-2 GB range. The three mechanisms — the adaptive index that inlines small edge lists, the collaborative update with pass-by-reference/value redistribution, and the tiny-chunk partitioning plus runtime rescheduling — are new as a combination, and the ablation study is unusually honest: every design has an on/off variant, and the speedups are large. The comparison against FAM-Graph and Gemini is useful, and the billion-scale datasets are not toy.\n\nThe main soft spot is the one the reader's report flags, and I think it is real: the system's central bet is that memory nodes can absorb offloaded update work (ValRD) without becoming the bottleneck, but the testbed simulates each MN with a 24-core EPYC running only two threads. Figure 26 shows peak CPU usage up to 44% on one EPYC core for the densest iteration. The paper's own background section (§2.2) assumes real MNs have 1-2 weak cores, and on such cores 44% of a strong core could easily become saturation, especially when the same node also serves RPC requests. If that happens, the collaborative update scheme loses its advantage and the 4.9x speedup over a single-node baseline becomes less representative. This is not a refutation, but it is a load-bearing assumption that needs a sensitivity study or at least a careful discussion.\n\nTwo smaller issues: the experiments appear to be single runs with no variance reported, and several thresholds (index size, RS threshold) look tuned on the same four graphs used for evaluation. Also, the headline 4.9x and 18.9x numbers compare different resource configurations (4 CNs vs 1 CN, per-CN cache vs aggregate). That is acceptable for showing elasticity, but it should be spelled out so readers don't over-read the numbers.\n\nWho this is for: systems researchers working on disaggregated memory, graph analytics, or RDMA-based storage systems. It deserves serious peer review — the architecture is original, the evaluation is substantial, and the limitations are identifiable rather than hidden. My recommendation: send it to referees, and ask for the artifact and a sensitivity analysis on MN CPU strength.","headline":"Genuinely new multi-CN/MN graph processing on DM, with a thorough ablation, but the MN-CPU assumption is tested only on 24-core EPYC nodes and could be the weak point.","tokens_in":28416,"tokens_out":4047,"would_cite":true,"duration_ms":38624,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims that DMG is the first practical graph processing system for disaggregated memory, one that scales across multiple compute and memory nodes while keeping compute-side caches at conventional DM sizes and delivering performan","keywords":["graph processing","disaggregated memory","RDMA","CXL","cache efficiency","graph partitioning","load balancing","graph store"],"falsifier":"Run the same BFS and PageRank workloads with memory nodes limited to one or two low-power cores and measure both end-to-end time and memory-node CPU utilization during the densest iteration; if any memory node’s utilization saturates or the end-to-end time degrades disproportionately, the collaborative-update claim collapses.","tokens_in":27455,"feed_emoji":"🕸️","tokens_out":5938,"duration_ms":54659,"temperature":0.7,"pith_summary":"Traditional distributed graph platforms couple CPU and memory in fixed-ratio servers, wasting resources; existing attempts to run graph analytics on disaggregated memory are stuck on one compute node and one memory node and demand tens of gigabytes of compute-side cache. DMG claims to be the first practical disaggregated-memory graph system that scales out both compute and memory elastically, needs only about 1–2 GB of cache per compute node, and still runs billion-edge graphs within roughly 40% of a local-memory distributed system’s computation time. It achieves this with a DM-friendly graph store that inlines short edge lists into the index, an adaptive update coordinator that moves update work to whichever node holds the destination vertex’s attributes, and a two-stage workload manager that partitions fast at startup and re-schedules hub vertices at runtime. If these claims hold, disaggregated memory stops being a toy for graph analytics and becomes a way to allocate graph memory independently of compute.","feed_headline":"Disaggregated memory runs billion-edge graphs at near-local speed","feed_subtitle":"DMG cuts compute-side cache up to 18.9x and scales graph jobs across many compute and memory nodes.","key_machinery":"The central mechanism is an adaptive per-vertex index and edge-store combined with a redistribute update path. The 32-byte per-vertex index lives in a single range-partitioned array on the memory pool; for low-degree vertices it stores the edge list inline (‘in-place’), turning two dependent remote reads into one, while for high-degree vertices it stores the edge-list address and compressed per-segment lengths (‘out-of-place’). The segment lengths let a node fetch only the portion of a hub’s edge list that falls in a given partition, and they let the update coordinator hand whole segments to the node that owns the destination attributes. This machinery converts RDMA’s IOPS bottleneck into fe","core_discovery":"The paper’s core discovery is that the three obstacles to practical graph processing on DM—IOPS-limited remote reads, costly remote update propagation, and tail effects from hub vertices—can each be turned around by exploiting where data already resides. DMG stores vertex attributes once in a shared memory pool and gives each compute node a small cache covering its assigned chunk. For retrieval, a 32-byte per-vertex index entry either embeds the edge list of low-degree vertices or stores a compressed segment layout for high-degree vertices, so most vertex reads become one merged RDMA request instead of two dependent fine-grained ones. For updates, a collaborative scheme batches update candid","pith_inferences":["The paper does not test memory nodes with truly scarce CPU: its memory nodes are 24-core servers running only two threads. If a real memory node has one or two weak cores, the offloaded ValRD update path could saturate that CPU, and the reported cache savings and speedups would shrink.","The in-place index scheme exploits power-law degree distributions; on graphs with more uniform degrees, fewer vertices fit inline and the retrieval benefit should diminish. The paper includes a synthetic R-MAT graph but does not isolate this effect.","The collaborative-update advantage depends on chunk locality; a graph whose vertex IDs are shuffled to destroy locality would send far more update candidates across the network. DMG does not report a degradation curve for such adversarial layouts.","Because the loaded graph store and segment metadata are reusable across different compute-node counts, a natural extension is mid-query elastic resizing of the compute pool without reloading the graph; the paper does not implement this."],"forward_implications":["Disaggregated-memory graph systems can store one copy of the graph in a shared memory pool and elastically add compute nodes without re-coupling memory, so tenants pay only for the resource they need.","A conventional 1–2 GB compute-side cache is enough for billion-scale graphs, because each compute node caches only the attribute slice of its assigned chunk; aggregate compute-node memory stays a small fraction of memory-pool usage.","Graph partitioning for load balancing can be redone in sub-seconds using tiny-chunk metadata, making repeated resource reconfiguration practical on DM.","The computation-time gap versus a local-memory distributed system stands at about 40%, and the paper argues this gap will narrow as interconnect bandwidth rises toward 800 Gbps and beyond.","The same storage and update techniques carry over to CXL-based memory pooling, because they reduce fine-grained remote accesses rather than relying on RDMA-specific behavior."],"fun_headline_variants":["DMG: first practical graph processing on disaggregated memory","Graph processing on disaggregated memory now scales and stays fast","Memory-disaggregated graph system cuts cache needs 18.9x and speeds up 4.9x","DMG enables elastic scaling for graphs on disaggregated memory","DMG: exploiting data locality for practical memory-disaggregated graphs"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The load-bearing premise is that a memory node’s scarce CPU can absorb the offloaded update work (ValRD) and RPC service without becoming a bottleneck—the testbed gives each memory node a 24-core server running only two threads, so the reported numbers depend on memory-node CPU being cheap.","fun_headline_variants_meta":{"raw":{"variants":["DMG: first practical graph processing on disaggregated memory","Graph processing on disaggregated memory now scales and stays fast","Memory-disaggregated graph system cuts cache needs 18.9x and speeds up 4.9x","DMG enables elastic scaling for graphs on disaggregated memory","DMG: exploiting data locality for practical memory-disaggregated graphs"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000935,"raw_usage":{"total_tokens":3860,"prompt_tokens":793,"completion_tokens":3067,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":537,"completion_tokens_details":{"reasoning_tokens":2970}},"tokens_in":537,"tokens_out":3067,"duration_ms":20910,"temperature":1.0,"reasoning_tokens":2970,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T09:05:10.017224+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same BFS and PageRank workloads with memory nodes limited to one or two low-power cores and measure both end-to-end time and memory-node CPU utilization during the densest iteration; if any memory node’s utilization saturates or the end-to-end time degrades disproportionately, the collaborative-update claim collapses.","supporting_citations":[],"review_version":1}