Linus 的独特放松方式：写内联汇编代码

作者 | Michael Larabel       译者 | 明明如月

责编 | 夏萌

出品 | CSDN（ID：CSDNnews）

"有些人通过在泳池边享用美酒来放松自己，而我则通过玩弄内联汇编来放松自己。" 这是 Linus Torvalds 在改进针对 Linux 6.5 合并窗口提出的性能优化补丁时爆出的金句。

正如一个月前在 Phoronix上 所写，一个针对 csum_partial 函数新增的补丁显著提升了吞吐效率并有效降低了延迟。这个函数在 Linux 内核中应用非常广泛，用于实现校验和（checksumming）功能。有了这个补丁，在特定场景下，延迟可能降低约 8~9%，吞吐效率也可能提高约 30%。

针对 csum_partial 的性能优化补丁已经被提交到 x86/misc（x86 架构中的杂项子系统）的拉取请求（pull request）中。在审查该代码过程中, Linus Torvalds 在邮件列表上留下了他的评论:

"说实话，我第一次看到这个补丁的反应是，'为什么选择以 64 字节的块进行处理，而不是更有趣的 40 字节？

更值得一提的是，后面还写着 '每 32 字节执行一次进位操作，以确保 32 字节块的独立性并提高指令级并行性(ILP)'。所以即便是在处理 64 字节的数据时，实际上并没有真正执行 64 字节的处理，而是并行执行了两个 32 字节的处理。

于是，在这里，出现了三个“神秘”的数字，64、40 和 32，然而最重要的可能只是 40 字节。

对，64 字节确实是常见的缓存行大小，且传统上也广泛使用。但在这个情境里，它并没有特别之处。

我的观点是：如果我们只处理 40 字节的块，把原来的“两个重叠的 32 字节块” 改为两个 40 字节的块，那会不会更好？

这就像我附上的那个（完全没有经过测试的！）补丁一样。

我要再强调一次：这完全是未经测试的。我只是快速查看了生成的汇编代码，虽然大致上符合我的预期，但也有可能毫无用处。

我在其中添加了一些 'likely()' 的标记，因为这会让生成的汇编看起来更顺畅并按照源代码的顺序执行，尽管这可能会引起一些争议（因为这基于我对代码执行情况的假设）。

最后一点：我已经说过，但我还要再强调，这完全是未经测试的。"

在发送以上信息后，他发现了自己手写汇编代码中存在一个简单失误，并做出了补正：

"我在重新山茶这个补丁时才发现了这个问题。我并没有进行任何实际测试验证其正确性。即便加入了那个 '+r'，它可能依然可能存在 bug，只是降低了一些错误罢了。

刚才被其他事情中断了，现在我要继续 “在代码的花园里挖呀挖” 了。有些人通过在泳池边享用美酒来放松自己，而我则通过玩弄内联汇编放松自己。

最后，Linus Torvalds 合并了原先的 csum_partial 优化补丁，而他自己的版本则仍在接受进一步的评论和讨论。

负责管理 x86/misc 拉取请求（pull request）的 AMD Linux 工程师 Borislav Petkov 对 Linus Torvalds 的言论作出了回应：

"还有第三种人，一边在泳池边享受美酒的惬意，一边沉迷于内联汇编的世界。;-P"