系统与数据库2024dl.gi.de
GPU 上的全规模文件系统加速
Full-scale file system acceleration on GPU
专业 · 约 60 分钟读完前置知识：操作系统与文件系统基础、GPU 架构与 CUDA 编程、PCIe 与设备 DMA 机制
导读
这篇论文提出在 GPU 上实现全功能的文件系统加速：通过将 PMem 直接映射到 GPU、并利用 P2PDMA 让 GPU 直接访问 NVMe 存储，绕过 CPU 完成文件系统操作，从而降低系统调用与数据搬运开销。作者还讨论了打开/读取/关闭文件等系统调用的开销问题。
HN 关注点：GPU 能否胜任文件系统这类对正确性要求极高的任务，讨论焦点包括 PCIe 点对点直传的可行性以及 GPU 驱动长期运行的稳定性。
HN 评论精选
这几条评论里：质疑 2 补充 2
补充指出 PCIe P2P 直传让 GPU 绕过 CPU 直接访问存储是可行且合理的
PCIe 允许数据在设备之间直接传输而不经过主机 CPU，所以让 GPU 直接从 NVMe（甚至 NVMe-oF）读块、而不是让 CPU 做大量工作，可能是合理的。补充：论文里确实写了——PMem 直接映射到 GPU，NVMe 内存通过 P2PDMA 访问。
magicalhippo查看英文原文
Given that PCIe allows data to be piped directly from one device to another without going through the host CPU[1][2], I guess it might make sense to just have the GPU read blocks straight from the NVMe (or even NVMe-of[3]) rather than having the CPU do a lot of work. edit: blind as a bat, says so right in the paper of course: PMem is mapped directly to the GPU, and NVMe memory is accessed via Peer to Peer-DMA (P2PDMA) [1]: https://nvmexpress.org/wp-content/uploads/Enabling-the-NVMe-CMB-and-PMR-Ecosystem.pdf [2]: https://lwn.net/Articles/767281/ [3]: https://www.nvmexpress.org/wp-content/uploads/NVMe_Over_Fabrics.pdf
质疑亲历经验：GPU 驱动不稳定，难以胜任文件系统/数据库这类不容出错的场景
我朋友曾在一家 GPU 数据库创业公司做集成工程师。他很沮丧，因为 GPU 驱动（AMD 和 Nvidia 都一样）本质上不稳定，不为长期无故障运行设计。深度神经网络里几个比特错了或游戏里一个像素错了没什么大不了，但在数据库（或文件系统）里就意味着一切！他前公司现在干脆提供无 GPU 加速的方案，虽然好用，但也失去了独特卖点。
multimind查看英文原文
A friend of mine used to work for a GPU database startup as an integration engineer. He got frustrated because GPU drivers ( not just AMD but also Nvidia ) are intrinsically unstable and not designed for long flawless runs. If a few bits have a wrong value in a deep neural network or a pixel is wrong in a game, it does not matter much. In databases ( or file systems for that matter ) it does mean everything! It is hard to believe at first, but his former company now offers solutions without GPU acceleration that simply work, but they also lost their USP.
质疑质疑论文对 open/close 系统调用开销的关注是否值得
有意思的是他们讨论了打开文件、读取、关闭的系统调用开销。似乎在几乎所有场景下，open 和 close 的开销都会被其他操作淹没。
ec109685查看英文原文
Interesting they would discuss system call overhead of opening a file, reading from it and closing it. Seems like in almost all cases the open and close calls would be overwhelmed by the other operations.
补充补充资料：已有用显存做虚拟磁盘的 GpuRamDrive 项目
虽然不是 1:1 的对比，但 Windows 上已有驱动可以从显存创建 RAM 盘：GpuRamDrive（用 GPU 内存做虚拟盘），还有支持 AMD 的 fork 以及修复并支持更多显卡的 fork。
molticrystal查看英文原文
While it is not a 1:1 comparison there has been a driver for windows that allows the creation of a ram drive from vram for NVIDIA cards. >GpuRamDrive >Create a virtual drive backed by GPU RAM. https://github.com/prsyahmi/GpuRamDrive Fork with AMD support: https://github.com/brzz/GpuRamDrive/ Fork that has fixes and support for other cards and additional features: https://github.com/Ado77/GpuRamDrive
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2024Hacker News 讨论帖148 分 · 45 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选