系统与数据库2019penberg.org编辑精选
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
进阶 · 约 30 分钟读完前置知识：操作系统基础、计算机体系结构、内核 I/O 路径
导读
这篇论文（Parakernel, HotOS'19）指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。作者提出按资源划分（partitioning）的思路，让应用绕过内核直接管理硬件资源，以消除或弱化 OS 抽象、释放硬件性能。
HN 关注点：'I/O 已不再是瓶颈'这一颠覆性前提，以及绕过内核抽象是否值得——讨论焦点集中在性能收益与把硬件复杂性转嫁给应用开发者之间的权衡。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 2
补充大型机 1970 年代的'通道'架构早已解决了外设直接访问内存的安全问题，微机照搬小型机模型是历史倒退
大型机设计者早在 1970 年就解决了这个问题。大型机有'通道'（channel），它是处理器架构的一部分：接收命令、发送给外设并管理双向数据传输。外设从不直接访问主存，没有外设控制的 DMA，因此可以把通道控制权交给用户态程序而没有内存安全风险。70 年代的小型机晶体管少、CPU 慢，外设被直接挂在内存总线上、可完全访问内存。微处理器照搬了小型机模型。IBM 的人知道这是坏主意，在 PS/2 中引入了'微通道'，但外设厂商因需要更多晶体管而强烈抗议，IBM 让步退回了总线型外设。这个模型延续至今，尽管如今几千个晶体管的通道控制器根本不算什么。
Animats查看英文原文
Mainframe designers had this problem under control by 1970. Mainframes had, and have, "channels". A channel is part of the processor architecture. It takes commands, sends them to a peripheral, and manages the data transfer in both directions. Channels have some privileged functions through which the OS tells them where the data is supposed to go in memory. The architecture of channels is well defined, and peripherals are built to talk to channels. The CPU has I/O instructions to control channels in a well defined way. The peripheral never has access to main memory. There is no peripheral-controlled "direct memory access" (DMA). So it's possible to give control of a channel to a userland program without a memory security risk. Minicomputers of the 1970s had low transistor counts and slow CPUs. So peripherals were usually put directly on the memory bus, with full access to memory. I/O operations were performed by storing into memory addresses, which caused bus transactions detected by the peripheral device. There were no CPU I/O instructions. Microprocessors copied the minicomputer model. IBM's people knew this was a bad idea, and in the IBM PS/2, they introduced the "microchannel". Peripheral vendors, facing a new architecture that required more transistors, screamed. IBM backed down and went back to bus-oriented peripherals. That model persists today, even though the few thousand transistors required for a channel controller are nothing today. Even though most modern CPUs have I/O channel like machinery, it's exposed to the program as registers the program stores into and memory accesses by the peripheral device. So there's no standardization on how to talk to devices at the hardware level. Some CPUs have protection systems, an "I/O MMU", and there have been various channel-like interfaces, especially from Intel, but they have never caught on. Instead, we mostly have heavy kernel mediation between the hardware and the user program. And way too many "drivers". This has become a problem with "solid state disk", which is really a random access memory device that doesn't write very fast. Mostly, it's used to emulate rotating disks. Samsung makes a key/value store device which uses SSD-type memory devices but manages the key/value store itself. But you need a kernel between the device and the user program. You can't just open a channel to it and let the user program access it.
支持数据库内核约五年前就已触及'I/O 不再是瓶颈'的拐点，基于新假设的设计与传统模型截然不同
至少在数据库内核领域，大约五年前在典型服务器硬件上就已明显达到这个阈值。这是个有趣的计算机科学问题：几乎所有数据库文献都建立在'I/O 远慢于 CPU'的假设之上。如果你以'I/O 不是瓶颈'为前提从零设计数据库内核，得到的架构会与大学里教的经典模型截然不同。这始终是用富余资源换取稀缺资源利用率的权衡，而老的数据库架构在新硬件上浪费的恰恰是变得相对稀缺的资源。
jandrewrogers查看英文原文
At least in database kernels, we noticeably reached this threshold around five years ago with typical server hardware. This is an interesting computer science problem in that virtually all of our database literature is based on the presumption that I/O is much slower than CPU. If you cleanroom a database kernel design based on the assumption that I/O performance is not the bottleneck, you end up with an architecture that looks very different than the classic model you learn at university. It is always a tradeoff of burning a resource you have in abundance to optimize utilization of a resource that is scarce, and older database architectures are quite wasteful of resources that have become relatively scarce on newer hardware.
质疑把硬件复杂性从内核转移到用户态对普通开发者是灾难，论文适用场景太小众，强调安全性站不住脚
这篇论文读起来像是建议把应对各种硬件接口的复杂性负担从内核转移到用户态，让用户态在硬件性能更高时直接利用它。我认为这只适用于极小的细分领域，总体上对行业是糟糕的发展。硬件厂商不喜欢共享：不共享代码、不共享通用接口、甚至不共享文档。目前这些问题大多数应用开发者都不用操心——它们由专门为不配合的硬件写支持的内核开发者处理。普通应用开发者不想为了打开一个网络连接就去搞清楚网卡支持多少队列；而且他们也没有足够的经验把这些做对。考虑到这些权衡适用的场景如此小众，我不明白论文为什么还要强调安全性。
thaumaturgy查看英文原文
The paper reads like it's suggesting moving the burden of complexity in dealing with varying hardware interfaces from the kernel to userland so that userland can take direct advantage of higher performance hardware when it's available. I could see that for some very small niches, but in general I think it would be a terrible development for the industry. Hardware vendors don't like to share. They don't share code, they don't share common interfaces, they don't even share documentation. As it is now, these are all problems which most userland developers don't have to care about -- those problems get dealt with in the kernel, by developers who specialize in building support for uncooperative hardware. The average application developer doesn't want to have to figure out how many queues are supported by a NIC just to open a connection on the network. Further: the average application developer isn't experienced enough to do this correctly. Given the niche where these tradeoffs make sense, I'm not sure why the paper bothers to emphasize security at all.
补充补充资料：Dan Luu 关于跨网络缓存层的文章及微软/谷歌在 100G RDMA 上的研究印证了这一趋势
我之前读到过一篇很棒的文章，Dan Luu 写的关于构建跨网络缓存层：https://danluu.com/infinite-disk/。我问了一个在量化交易公司工作的朋友，他说确实如此，而且相当疯狂。微软和谷歌似乎也在研究基于 100G 以太网的 RDMA 用于数据中心内部通信。很酷。
yingw787查看英文原文
There was a great blog post I read a while back about constructing a caching layer across network by Dan Luu: https://danluu.com/infinite-disk/ I asked a friend who works in a quant firm and he was like yes it’s true, and it is pretty insane. I think there’s research Microsoft and Google are doing for RDMA over 100G Ethernet for intra data center communication as well. Pretty neat.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2019Hacker News 讨论帖817 分 · 277 评
同领域还值得读
使用 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 分钟编辑精选SQLite：过去、现在与未来
SQLite: Past, Present, and Future
这篇 VLDB 论文梳理 SQLite 的历史、当前架构与性能表现，并展望未来方向。
系统与数据库2022 · 282 分 · 86 评进阶 · 约 40 分钟编辑精选