系统与基础设施mazzo.li编辑精选
Linux 管道到底有多快？
How fast are Linux pipes anyway?
2022 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章通过逐步优化一个用管道传输数据的程序，深入剖析了 Linux 管道的性能极限，涉及 vmsplice、零拷贝、页缓存等内核机制，并配有手绘图解。作者把管道吞吐量从几 GB/s 一路提升，展示了系统级优化的完整思路。
为什么经久不衰：它把枯燥的内核机制讲得清晰透彻，且揭示了 vmsplice 等技巧的安全隐患，是系统编程优化的经典教材，多年后仍有参考价值。
HN 评论精选
指出文中 vmsplice 优化方案存在页面生命周期不安全的问题，实际使用范围有限
这篇文章写得很好，讲解出色，我读得很享受。不过，所有使用 vmsplice 的变体（除了最慢的那个）都不安全。当你把页面“赠予”内核时，没有可靠通用的方法知道这些页面何时可以安全复用。文章假设写入“管道大小”字节后页面即可复用，但这并不普遍成立——例如读端也可能用 splice 类调用把页面零拷贝地移到其他管道或 IO 队列，页面生命周期会超出原管道。这会导致竞态条件和数据自发变化。splice 的作者 Jens Axboe 曾提议一种确定页面何时可安全复用的机制，但据我所知从未被合并。所以这些方法只适用于你能控制管道两端、确切掌握页面生命周期的场景。
BeeOnRope查看英文原文
This is a well-written article with excellent explanations and I thoroughly enjoyed it. However, none of the variants using vmsplice (i.e., all but the slowest) are safe. When you gift [1] pages to the kernel there is no reliable general purpose way to know when the pages are safe to reuse again. This post (and the earlier FizzBuzz variant) try to get around this by assuming the pages are available again after "pipe size" bytes have been written after the gift, _but this is not true in general_. For example, the read side may also use splice-like calls to move the pages to another pipe or IO queue in zero-copy way so the lifetime of the page can extend beyond the original pipe. This will show up as race conditions and spontaneously changing data where a downstream consumer sees the page suddenly change as it it overwritten by the original process. The author of these splice methods, Jens Axboe, had proposed a mechanism which enabled you to determine when it was safe to reuse the page, but as far as I know nothing was ever merged. So the scenarios where you can use this are limited to those where you control both ends of the pipe and can be sure of the exact page lifetime. --- [1] Specifically, using SPLICE_F_GIFT.
分享实际经验：管道本身才是瓶颈，单个程序再快也没用
我曾不得不修正自己对这类程序速度的心理模型。我用 seq 作为输入，以为它是个在 CPU 上热运行的小生成器程序，只写内存不读数据，应该飞快。但实际慢得离谱。我写了个更快的版本，但最后发现这无关紧要——因为通过命令行管道传给下一个程序才是瓶颈。
nice2meetu查看英文原文
I once had to change my mental model for how fast some of these things were. I was using `seq` as an input for something else, and my thinking was along the lines that it is a small generator program running hot in the cpu and would be super quick. Specifically because it would only be writing things out to memory for the next program to consume, not reading anything in. But that was way off and `seq` turned out to be ridiculously slow. I dug down a little and made a faster version of `seq`, that kind of got me what I wanted. But then noticed at the end that the point was moot anyway, because just piping it to the next program over the command line was going to be the slow point, so it didn't matter anyway. https://github.com/tverniquet/hseq
在 Mac Studio 上复现基础实现，速度反而超过作者的测试结果
我在 Mac Studio 上跑了文章最初的基础实现，惊喜地看到 pipetest 达到 8 GB/s，而 pv 读 /dev/null 是 36.4 GB/s。虽然不知道作者用的什么机器、无法直接比较，但 macOS 在这种对比中很少出彩，而这个简单实现比作者的 3.5 GB/s 还快，超出我的预期。
spacedcowboy查看英文原文
Ran the basic initial implementation on my Mac Studio and was pleasantly surprised to see @elysium pipetest % pipetest | pv > /dev/null 102GiB 0:00:13 [8.00GiB/s] @elysium ~ % pv < /dev/zero > /dev/null 143GiB 0:00:04 [36.4GiB/s] Not a valid comparison between the two machines because I don't know what the original machine is, but MacOS rarely comes out shining in this sort of comparison, and the simplistic approach here giving 8 GB/s rather than the author's 3.5 GB/s was better than I'd expected, even given the machine I'm using.
称赞文章内容有深度且排版美观
这是一篇很长但极具启发性的阅读！（另外，那种字体配手绘图的组合真的很酷）
herodoturtle查看英文原文
This was a long but highly insightful read! (And as an aside, the combination of that font with the hand-drawn diagrams is really cool)
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选