Sep 2026· Proceedings of the 18th ACM Workshop on Hot Topics in Storage and File Systems· pp. 99-104· 0 citations· 8 references
TL;DR
Nexus is presented, a quasi-user-space I/O stack with a split architecture: a user-space data plane and a lightweight kernel control plane that enables efficient memory usage through shared data structures and in-kernel page reclamation that coordinate global allocation and reclamation across all processes.
Abstract
Modern NVMe SSDs push the I/O bottleneck into software. Kernel-bypass frameworks accelerate direct I/O but leave buffered I/O, the dominant mode in practice, unoptimized. We show that small buffered I/O (32 B–4 KB) incurs a 2–15 × kernel overhead and dominates real server and mobile workloads. Existing user-space caches fail to simultaneously meet four key properties: file-level caching, low access overhead, hardware agnosticism, and efficient memory usage. While the first three can be achieved by moving the page cache to user space, efficient memory usage remains elusive due to the lack of system-wide coordination across isolated process address spaces. This paper presents Nexus, a quasi-user-space I/O stack with a split architecture: a user-space data plane and a lightweight kernel control plane. The data plane performs cache lookups and I/O submission with zero system calls, thereby delivering file-level caching, low access overhead, and hardware agnosticism. The control plane, in turn, enables efficient memory usage through shared data structures and in-kernel page reclamation that coordinate global allocation and reclamation across all processes. Our evaluation shows that Nexus achieves up to 3.4 × throughput for small sequential reads and 1.5–1.8 × for random reads over ext4 with dynamic and efficient memory usage.
A crash-consistent I/O cache is essential to ensure data integrity while optimizing performance. However, a general-purpose kernel fails to ensure integrity efficiently because of the high cost of synchronizing I/O requests with the many subsystems that rely on the cache. As a consequence, applications that must store...
Jana Toljaga, Nicolas Derumigny, Tara Aggoun et al.· Proceedings of the ACM SIGOP...· 0 citations
This poster observes the stall from inside the kernel, using the multi-volume data placement proposed in SteelDB as the experimental lever to observe the stall from inside the kernel.
Wider vector/SIMD lanes multiply compute throughput, but cache improvements remain challenging. We identify L1 data cache capacity as the most impactful parameter for performance and efficiency. L1 capacity is constrained by pipeline coupling and latency requirements; private L2 offers an order of magnitude more capaci...
Jing-Qun Zhang, Mao-Hua Nie, Jia-Yi Wang et al.· 0 citations
A simple read interface provides uniform functional semantics, but not equally simple or predictable performance behavior. We use synchronous large-buffer reads in Linux as an observation window and decompose the buffered-read path end to end, distinguishing work volume, processing time, and critical-path exposure. We...
NVIDIA's Grace Hopper (GH200) superchip represents a new generation of heterogeneous computing, tightly integrating a 72-core Arm-based CPU with a Hopper GPU on a single module via a high-bandwidth, cache-coherent interconnect. By eliminating the conventional PCIe bottleneck for CPU-GPU data movement, this design estab...
Ravan Nazaraliyev, Yi-Cheng Zhang, Nael B. Abu-Ghazaleh· 0 citations
LLM serving reuses cached key-value (KV) state to skip prefill, and growing contexts push that state past GPU HBM and CPU DRAM onto NVMe SSDs, placing prefix restore on the critical path of time-to-first-token (TTFT). We find that on a well-configured host-issued path the SSD is not the bottleneck: restoring the same 6...
Ding-Sen Shi, Jia-Hao Zhang, Li-Qiang Lv et al.· 0 citations
We use cookies to run the site and, with your consent, for analytics and to show ads.
See our Cookie Policy.