SearcharxivSearch

arXiv subjects

Mark Heinrich

Publications and source records attributed to Mark Heinrich.

3 recordsLinked to original sources

Distributed Persistence Domain for Persistent Memory Pooling

Compute Express Link (CXL) enables memory pooling over disaggregated memory, offering the potential to improve resource utilization in persistent memory systems. However, integrating persistence semantics into CXL-based memory pooling introduces substantial latency, which limits system scalability. This overhead arises because persist operations must traverse the entire CXL fabric, including switches, links, and protocol layers, before reaching remote persistent memory. To this end, we argue that extending CXL switches with persistence support is a promising direction for improving the scalability of persistent memory pooling. However, moving persistence support into the network breaks the traditional correctness assumptions of centralized persistence domains. In particular, enabling persistence within distributed structures, such as CXL switches, can introduce stale reads and writes if not carefully coordinated. In this paper, we propose Distributed Persistence Domain (DPD), a new abstraction for persistent memory pooling that enables persistence support at the CXL switch level. We first formalize the concept of a distributed persistence domain and use DPD as a framework to identify the correctness hazards that arise when persistence structures are distributed across the CXL fabric. Based on this analysis, we derive the design requirements needed to guarantee correctness. Building on these insights, we present Persistent CXL Switch, a CXL switch architecture that incorporates persistence support to significantly reduce persist latency, enable read forwarding, and coalesce writes, while preserving correctness and crash consistency. We evaluated our system design using both SPLASH-4 and YCSB benchmarks. Simulation results show an average speedup of 33% over volatile CXL switches, and up to 36% speedup with read forwarding optimization across all workloads.

cs.ET

The Case for Persistent CXL switches

Compute Express Link (CXL) switch allows memory extension via PCIe physical layer to address increasing demand for larger memory capacities in data centers. However, CXL attached memory introduces 170ns to 400ns memory latency. This becomes a significant performance bottleneck for applications that host data in persistent memory as all updates, after traversing the CXL switch, must reach persistent domain to ensure crash consistent updates. We make a case for persistent CXL switch to persist updates as soon as they reach the switch and hence significantly reduce latency of persisting data. To enable this, we presented a system independent persistent buffer (PB) design that ensures data persistency at CXL switch. Our PB design provides 12\% speedup, on average, over volatile CXL switch. Our \textit{read forwarding} optimization improves speedup to 15\%.

cs.AR

Persistent Memory Objects: Fast and Easy Crash Consistency for Persistent Memory

DIMM-compatible persistent memory unites memory and storage. Prior works utilize persistent memory either by combining the filesystem with direct access on memory mapped files or by managing it as a collection of objects while abolishing the POSIX abstraction. In contrast, we propose retaining the POSIX abstraction and extending it to provide support for persistent memory, using Persistent Memory Objects (PMOs). In this work, we design and implement PMOs, a crash-consistent abstraction for managing persistent memory. We introduce psync, a single system call, that a programmer can use to specify crash consistency points in their code, without needing to orchestrate durability explicitly. When rendering data crash consistent, our design incurs a overhead of $\approx 25\%$ and $\approx 21\%$ for parallel workloads and FileBench, respectively, compared to a system without crash consistency. Compared to NOVA-Fortis, our design provides a speedup of $\approx 1.67\times$ and $\approx 3\times$ for the two set of benchmarks, respectively.

cs.OS