{"id":"1c21db00-7ac3-4412-9fda-e66268dfe066","arxiv_id":"2607.15569","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"xDSM scales unmodified pthread applications across CXL-connected nodes with full-address-space sharing, latency-driven page placement, and elastic 4KB–2MB page management, reporting 1.5–2.2× gains over CXL-only baselines.","lead":"xDSM is a software system that lets ordinary multithreaded programs run across several computers joined by CXL shared memory without rewriting the programs. It decides which memory pages should live in fast local RAM versus slower shared CXL memory, and adjusts page size on the fly, claiming 1.5–2.2× speedups over CXL-only setups.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Single-OS NUMA emulation never exercises cross-OS address-space coordination, so the full-space transparency claim is unverified.","rationale":"The paper is a coherent systems design with a broad evaluation, and the authors are transparent about the CXL 3.0 hardware limitation. However, the most load-bearing weakness is more specific than the reader's latency-focused concern: the evaluation does not validate the system's ability to coordinate address spaces across independent OSes, which is essential to the claim of transparently scaling unmodified multithreaded applications. The NUMA emulation retains a single kernel and a single address space, so the full-space sharing and distributed thread management components are effectively assumed rather than demonstrated. This is not an ad hominem or a claim of inconsistency; it is a gap between the claimed deployment scenario and the measured one. The proposed multi-OS test directly targets this gap. Since the reader's verdict is already CONDITIONAL and this concern reinforces the need for additional validation, the verdict remains CONDITIONAL (UNCHANGED).","tokens_in":22059,"tokens_out":13400,"duration_ms":149551,"concrete_test":"Run the five benchmarks (or at least PageRank and Jacobi) with xDSM on two independent Linux instances (e.g., two KVM VMs on the same host, each with its own kernel, sharing a memory-mapped file or virtio-shmem device as a CXL-like shared memory) with threads dispatched across instances via the runtime's remote thread mechanism. If the unmodified pthread programs fail to execute or the end-to-end time relative to CXL-ONLY falls outside the claimed 1.5–2.2× range, the central transparency and scalability claim is unsupported. A minimal version: start a pthread program on VM A, dispatch one thread to VM B, and verify that globals, heap, and stack are accessible at identical virtual addresses; then measure page-fault and migration overheads against the single-OS emulation.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that xDSM transparently scales unmodified multithreaded applications across CXL-connected nodes. Section 8.1 states that four NUMA domains of a single AMD EPYC server emulate four independent compute nodes, but real CXL 3.0 nodes run separate OSes with isolated page tables and VMAs. In the evaluation, all threads run inside one Linux instance and share a single process address space; the .text/.data/.bss/heap/stack sharing described in §4 is just ordinary pthread semantics, not a coordinated global address space across OSes. The startup mechanism in §7 (process_vm_readv to copy pages into CXL) is a single-process operation and does not demonstrate how a separate OS on another host maps the same virtual addresses and receives dispatched threads. Consequently, the system's core novelty—full-space sharing for unmodified pthreads across independent OSes—is not exercised. Measured page-fault, PTE-update, and TLB-shootdown costs are local-kernel costs; remote hypercalls, inter-node TLB invalidations, and distributed VMA anchoring are absent. The 1.5–2.2× speedups and near-linear scaling therefore rest on an untested functional assumption, not merely on a latency-matching issue.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"xDSM is a CXL-based distributed shared memory system that aims to run unmodified multithreaded (pthread) applications across multiple nodes. The paper makes three architectural claims: (1) a full-space shared execution environment that shares .text/.data/.bss/heap/stack without code modification; (2) a latency-driven dynamic placement policy based on exponentially binned latency histograms and P90-bin alignment; and (3) elastic page management that coalesces and splits pages between 4 KB and 2 MB to amortize page-fault costs and avoid false sharing. The evaluation uses four NUMA domains of a single AMD EPYC server with a CXL 1.1 Type-3 memory expander, compares 15 configurations across five benchmarks plus an LLM inference workload, and reports speedups of 1.5–2.2× over CXL-only baselines, 1.1–2.2× over hybrid DSMs, and near-linear to superlinear scaling.","tokens_in":22375,"tokens_out":7466,"duration_ms":81429,"significance":"If the claims hold, xDSM would be a substantial advance: it addresses three real limitations of existing CXL-based DSMs—heap-only sharing, static page placement, and fixed page granularity—with a coherent OS-runtime co-design. The evaluation is broad and thoughtful: five benchmarks with distinct access patterns, 15 system configurations, a dynamic MoE/LLM workload with SLA-based goodput, and comparisons to Memtis+, Colloid+, and Alto+Colloid+. The implementation effort is also significant (~23,800 LOC for xDSM plus ~8,300 LOC for comparison systems). However, the central multi-node, cross-OS capability is never exercised: the four \"nodes\" are NUMA domains of a single Linux instance, so the headline claim of transparently scaling unmodified applications across independent OSes rests on an untested functional assumption. In addition, the quantitative results are reported from single runs with no error bars or repetition counts. These issues are load-bearing for the paper's main contributions, so a major revision is required.","major_comments":[{"comment":"The evaluation never exercises the central claim of transparent full-space sharing across independent compute nodes. As stated in §8.1, the four \"nodes\" are four NUMA domains of one AMD EPYC system running a single Linux instance; all application threads share one address space and one kernel. The startup path in §7 reads /proc/self/maps and uses process_vm_readv, which are single-OS, single-process operations; the \"globally coordinated address space\" of §4.1 and the VMA-anchored transfers of §4.2 are local PTE operations. Cross-OS issues — independent page tables and VMAs per node, remote thread dispatch, inter-node TLB invalidation, distributed VMA anchoring, cross-OS synchronization of global mappings — are never exercised. The 1.5–2.2× and near-linear scaling claims therefore rest on an untested functional assumption, not merely on a latency-matching difference. Please provide a mult","section":"§8.1, §4, §7"},{"comment":"Equation (1) as printed is inconsistent with the bin mapping shown in Figure 2. For ℓ in [512,1023], ⌊log2ℓ⌋ = 9; if the first term means 2^{⌊log2ℓ⌋−4}, the bin index is 32, not 10 as shown in the figure; if it means 2(⌊log2ℓ⌋−4), the expression is missing required parentheses. The text describes intervals [2^k, 2^{k+1}) bisected into two bins, but the printed formula lacks the floor/offset structure needed to produce indices 10 and 11 for [512,767] and [768,1023]. Since P90-bin alignment is the core of the placement policy, this must be corrected and the formula made unambiguous.","section":"§5.1, Eq. (1), Figure 2"},{"comment":"No repetition counts or error bars are reported for any end-to-end measurement. Figures 3–8 each show a single trajectory or a single bar per configuration, and the speedup ranges in the abstract and §1 (1.5×–2.2×, 1.1×–2.2×, 5.1×) appear to be computed from these single runs. For runtime measurements on shared hardware, and especially for claims of superlinear scaling, at least 3–5 repetitions with variance (or a justification that results are deterministic) are needed to establish that the reported differences are not noise.","section":"§8.3–§8.7, Figures 3–8"},{"comment":"The hardware does not match the coherence model assumed by the design. The design in §2.1 relies on CXL 3.0 multi-node BISnp for hardware-managed cache coherence. The evaluation uses a CXL 1.1 Type-3 expander attached to one host; CXL 1.1 does not implement multi-host BISnp. The statement that \"CXL 1.1 supports hardware cache coherence within a single machine, satisfying the requirements of our systems\" conflates single-host CPU cache coherence with the multi-node coherence assumed by the design. The measured overheads therefore include whatever software consistency the system implements, not the BISnp hardware path. Please clarify what coherence is actually provided by the experimental setup and how it maps onto the assumed CXL 3.0 substrate.","section":"§8.1, §2.1"}],"minor_comments":[{"comment":"Typo in contributions bullet: \"three fundermental limitations\" should be \"three fundamental limitations.\"","section":"§1"},{"comment":"Typo in \"up to 2,MB\": should be \"2 MB.\"","section":"§3.1"},{"comment":"The definition of P90 bin as \"the lowest index encompassing at least 90% of samples\" should specify whether accumulation is from the low end, how ties are broken, and what happens when samples are split across the maximum bin.","section":"§5.1"},{"comment":"The description of Memtis+, Colloid+, and Alto+Colloid+ says they were \"adapted to our batch migration runtime\" but gives no details of the adaptation. Without this, the reader cannot assess whether the comparison is fair or whether the adaptations disadvantage the baselines.","section":"§8.6"},{"comment":"Typo: \"eptp_database\" should be \"xdsm_database.\"","section":"§9"},{"comment":"The paper says \"All source code will be open-sourced upon publication,\" but no artifact or DOI is provided. Given that the evaluation is the main evidence, an artifact appendix with code and configuration scripts would improve reproducibility.","section":"§7"}],"recommendation":"major_revision","confidential_remarks":"For the editor: I am sympathetic to the difficulty of obtaining CXL 3.0 multi-host hardware, but the current evaluation is an emulation that leaves the headline capability — unmodified pthreads across independent OSes — unverified. If the authors cannot provide at least a separate-kernel demonstration (e.g., two VMs with independent page tables sharing a CXL device) plus repeated runs, I would not be comfortable accepting. The paper may also need a revised title/abstract if the system is only evaluated within a single OS."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague — two things up front. First, this is a serious systems paper with a coherent design: full-space sharing via coordinated global addressing and VMA-anchored transfers, latency-driven placement via P90 exp-bin histograms, and elastic 4KB–2MB page coalescing. Each piece has lineage, but the integration and the evaluation breadth are real. Second, the central claim — transparently scaling unmodified pthread programs across independent CXL-connected nodes — is not actually exercised. The stress-test note is correct: four NUMA domains on one EPYC server run one Linux image. All threads share one address space, so the hard parts of multi-OS coordination (same virtual addresses on separate page tables, VMA anchoring across kernels, remote thread dispatch, inter-node TLB shootdowns) don't happen. process_vm_readv at startup is a single-process operation, not a demonstration of another OS mapping the same VAs. The measured page-fault and PTE costs are local-kernel costs. That makes the headline performance an emulation of the memory-tiering story, not of the cross-node DSM story.\n\nWhat the paper does well: the three mechanisms are cleanly motivated, and the 15-configuration evaluation is unusually thorough for this space. The LLM dynamic workload is a nice addition, and Section 9's admission about CXL switches is honest. The placement-policy comparison to Memtis+/Colloid+ is useful. I also appreciate that they state the CXL 3.0 hardware limitation in the text.\n\nSoft spots, in proportion. The emulation issue is the big one; it doesn't invalidate the dynamic-placement/elastic-granularity results within a single OS, but it leaves the full-space transparency claim unverified. There are no error bars or repetition counts, the α values (2 and 4) are hand-set with no sensitivity analysis, and no code or data is released, so the numbers aren't independently checkable. Equation (1) is confusingly typeset and should be cleaned up; it's probably consistent with Figure 2 if read as powers of two, but as printed it invites error.\n\nWho this is for: systems folks working on CXL memory pooling, tiered memory, or DSM. I'd send it to peer review rather than desk reject — a good referee can force the authors to either test on genuinely independent OSes (even if that means a more limited real-hardware study) or soften the transparency claim, and to release artifacts. I wouldn't take the 1.5–2.2× speedups at face value until that happens.","headline":"Plausible design, honest but limited evidence: the full-space cross-OS claim is asserted, not tested, and the 1.5–2.2× numbers rest on single-OS NUMA emulation.","tokens_in":22872,"tokens_out":3047,"would_cite":true,"duration_ms":34797,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"xDSM shows a CXL-connected cluster can run unmodified multithreaded programs by sharing every memory segment and varying page size on the fly.","keywords":["distributed shared memory","CXL","elastic page granularity","page placement","full-space sharing","multithreaded programs","latency histogram","memory tiering"],"falsifier":"Run the same five benchmarks on a genuine CXL 3.0 multi-node system with 4 nodes, comparing xDSM against CXL-only and a fixed-granularity hybrid. If xDSM's advantage over CXL-only drops below about 1.1x, or if the measured page-fault processing time does not drop and amortize as the paper assumes, the central claim would be falsified.","tokens_in":21958,"feed_emoji":"⚡","tokens_out":5967,"duration_ms":60595,"temperature":0.7,"pith_summary":"The paper presents xDSM, a distributed shared memory system that lets ordinary pthread programs run unchanged across CXL-connected machines. It mounts three challenges that earlier DSM systems left open: share every memory segment (not just heap), replace static page placement with a latency-driven policy that balances data between local DRAM and CXL memory, and manage memory at variable granularity from 4 KB to 2 MB to cut page-fault overhead while avoiding false sharing. Evaluated across five benchmarks and 15 system configurations, xDSM reports 1.5x to 2.2x speedups over CXL-only execution, 1.1x to 2.2x over state-of-the-art hybrid DSMs, and near-linear scaling from 1 to 4 nodes. A sympathetic reader can care because it promises to scale existing multithreaded applications across machines without rewriting them into message passing or manually partitioning data.","feed_headline":"Multithreaded apps scale across CXL nodes without rewrites","feed_subtitle":"Elastic pages and latency-driven placement deliver 1.5x-2.2x speedups over CXL-only memory and near-linear scaling.","key_machinery":"The central object is the elastic page: a variable-sized unit from 4 KB to 2 MB that the runtime forms by coalescing contiguous base pages that share the same accessors and consistency state, and that it splits on write faults. It carries metadata, fault resolution, and migration, so it determines the system's performance. Three mechanisms support it: VMA-anchored page transfers, which update only page table entries and leave the VMA pointing at the CXL backing store, making fast-path migration cheap; exp-binned latency histograms with P90-bin alignment and gap-proportional, asymmetric migration volume, which drive placement by measured latency rather than static rules; and the xdsm_database","core_discovery":"The paper's central claim: an OS-runtime co-design can turn CXL shared memory into a full-space DSM that runs unmodified pthread programs. xDSM maps the entire application layout to shared CXL memory and assigns disjoint virtual ranges per node, so globals, statics, heap, and stack are shared. Placement follows latency equilibrium: sampled latencies go into exponentially scaled bins, and pages migrate between local DRAM and CXL in proportion to the 90th-percentile bin gap, with aggressive promotion and throttled demotion. The management unit is an elastic page that coalesces contiguous base pages with matched accessors and consistency state, and splits on write faults. The author's claim: th","pith_inferences":["If real CXL 3.0 multi-node deployments present higher remote latency than the NUMA emulation used here, as the paper itself notes, the benefit of promoting hot pages locally should grow rather than shrink, but the 1.5x-2.2x numbers are not guaranteed to transfer intact.","A natural test outside the DSM setting is to bolt the gap-proportional P90-bin migration policy onto an ordinary two-tier memory manager and measure whether it beats frequency-based promotion on real CXL hardware.","The elastic-page idea could generalize to other coherence protocols or to object-granularity DSM: the same coalesce-on-quiet/split-on-write rule may reduce protocol traffic in non-CXL contexts as well.","The design assumes the shared metadata in CXL memory is trusted; before multi-tenant or untrusted deployments, that state needs hardware-enforced protection, which the paper leaves to future work."],"forward_implications":["Unmodified pthread programs, including their global and static variables, can execute across CXL-connected machines with no code rewriting.","Latency-driven placement keeps both local DRAM and CXL memory working, giving read-shared workloads a path around the latency penalty of placing all shared data on CXL.","Elastic pages amortize page-fault costs by batching up to 512 contiguous pages per fault, which yields faster warm-up and steadier throughput than fixed 4 KB pages.","Workloads larger than the aggregate local DRAM of all nodes become runnable, since CXL memory serves as a shared overflow tier.","In the paper's trace-driven LLM inference test, the design raises goodput by 1.13x over a fixed-page hybrid and 1.91x over CXL-only execution."],"fun_headline_variants":["xDSM scales unmodified pthread apps on CXL memory","Elastic CXL DSM: 1.5x-2.2x faster, no app rewrites","Latency-aware CXL pages enable near-linear scaling","No-rewrite CXL DSM with dynamic page splitting","CXL shared memory that just works for multithreaded apps"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The evaluation assumes that four NUMA domains of a single server with a CXL 1.1 memory expander behave like a real CXL 3.0 multi-node cluster; if switch latencies or back-invalidation coherence overheads differ on genuine hardware, the reported speedups may not hold.","fun_headline_variants_meta":{"raw":{"variants":["xDSM scales unmodified pthread apps on CXL memory","Elastic CXL DSM: 1.5x-2.2x faster, no app rewrites","Latency-aware CXL pages enable near-linear scaling","No-rewrite CXL DSM with dynamic page splitting","CXL shared memory that just works for multithreaded apps"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000269,"raw_usage":{"total_tokens":1495,"prompt_tokens":818,"completion_tokens":677,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":562,"completion_tokens_details":{"reasoning_tokens":583}},"tokens_in":562,"tokens_out":677,"duration_ms":7234,"temperature":1.0,"reasoning_tokens":583,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T22:54:33.450890+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same five benchmarks on a genuine CXL 3.0 multi-node system with 4 nodes, comparing xDSM against CXL-only and a fixed-granularity hybrid. If xDSM's advantage over CXL-only drops below about 1.1x, or if the measured page-fault processing time does not drop and amortize as the paper assumes, the central claim would be falsified.","supporting_citations":[],"review_version":1}