关注了就能看到更多这么棒的文章哦～

Fedora's tempest in a stack frame

By Jonathan Corbet
January 16, 2023
DeepL assisted translation
https://lwn.net/Articles/919940/

很少看到在讨论编译器选项的时候会出现非常深入并且不太愉快的讨论，但确实还是有的。有一个典型的例子就是关于 Fedora 是否应该使用 frame pointer 的讨论。这里需要在当前系统受到性能损失以及未来有希望获得超过该损失的收益之间进行权衡，还有 Fedora 社区内对如何做出这些决定的一些分歧。

一个 stack frame 中，包含了当前运行程序里的一个函数调用所相关的信息，其中这包括返回地址、局部变量以及保存下来的寄存器值。frame pointer （帧指针）是一个 CPU 寄存器，指向当前的 stack frame 的 base 地址；每当从一个函数返回时，知道这个地址就可以正确地清理 frame pointer 了。不过，编译器很清楚他们在 stack 上分配了多少空间，实际上不需要 frame pointer 就可以正确地管理 stack frame。因此，通常编译程序时不使用 frame pointer。

不过其他代码就显然不了解编译器的这些内部状态了，可能会很难对 stack 的内容进行解析。因此，没有 frame pointer 的代码可能更难进行 profile （性能采集分析）或获得有用的 crash dump 文件。如果有 frame pointer 的话，进行调试和性能优化都会变得更容易。

早在 2022 年 6 月就提出过一个针对 Fedora 37 版本的 Fedora 全系统范围内的修改建议，要求对所有为该发行版构建的二进制文件都启用 frame pointer。虽然开发者在需要时可以相对容易地用 frame pointer 来编译构建某个特定的程序，但该提案指出这个工作通常也需要重新编译许多库；这使得这项工作变得更加困难。有些类型的 profile 需要在整个系统的基础上进行才有用；这只有在整个系统都启用 frame pointer 的情况下才能做到。如果直接从一开始就以这种方式构建发行版，可以使开发者的生活更加轻松，而且，有人认为，这为将来的许多性能改进创造了条件。

当然，启用 frame pointer 是有代价的。每个函数调用都必须将当前的框架指针保存到堆栈中，这就会略微增加该调用的开销，以及增大代码 size。frame pointer 还占用了一个通用寄存器，这会导致更容易出现寄存器不够用的情况，并减慢了可能会更好地使用该寄存器的代码。发行版最开始没有使用 frame pointer 的主要原因就是要避免这些开销。

这个提议在邮件列表和相关的 Fedora 工程指导委员会(FESCo)票据上引起了广泛讨论。正如人们所预期的，主要的反对意见都是来自性能开销，其中一些已经在 Fedora wiki 上做了 benchmark 测试。编译内核的速度慢了 2.4%，Blender test 出现了 2% 的损失。最糟糕的情况似乎是 Python 程序，可以看到高达 10%的性能损失。在许多人看来，这些代价是不可接受的。

这些直接反响足以导致提议的修改被推迟到 Fedora 38。但讨论仍在继续。支持这一改动的人并没有被任何潜在的性能损失所吓倒；例如，Andrii Nakryiko 认为：

即使我们在 benchmark 中损失了 1-2%的性能，我们其实可以使得很多系统爱好者开始做具体的分析和调查，而不需要重新用特殊的配置来编译系统或应用程序了。如果试图在这个领域做一点有用的工作都需要花费大量的精力，这对人们在性能和效率方面的贡献是多么大的一个阻碍，这一点被极度低估了。如果我们关心社区的贡献，我们需要让社区能很简单地就对应用程序进行观测。

他补充说，Meta 公司在构建其内部应用程序时启用了 frame pointer，因为认为这些开销所带来的收益足够有吸引力了。Brendan Gregg 描述了在 Netflix 看到的 frame pointer 带来的好处，Ian Rogers 也讲述了在 Google 的类似经历。另一方面，以 Florian Weimer 为代表的 Red Hat 平台工具团队的开发者们仍然坚定地反对启用 frame pointer。相反，Neal Gompa 支持这一改变，但他担心 Fedora 会因为降低整个发行版的性能而在某些以基准为导向的网站上被 "放在火上烤"。

在 11 月 15 日的 FESCo 会议上讨论了这一变化（IRC log 有记录），该提案最终被否决。这导致了支持改革者的一些不满，他们不愿意放弃这个想法，尽管 Kevin Kofler 告诫说 "toolchain 开发者在这个问题上是最权威的专家"，是时候该看些别的工作了。Michael Catanzaro 抱怨说，他 "从 toolchain 开发者对这个问题的处理来看，不能再信赖他们对现实世界中的性能影响能做出理性的决定"。但即使是 Catanzaro 也说，现在是时候放弃了。

但事实并非如此。1月 3 日，FESCo 召开了另一次会议，会上讨论了一个全新的议题，要求对 frame pointer 提案进行 "重新投票"；这是大多数人第一次听说这个想法又出现了。这个新的 ticket 在六天前（12 月 28 日）由 Gompa 开启；它以六票对一票（一票弃权）获得通过。因此，截至目前的结论是，计划在 Fedora 38 版本中启用 frame pointer，该版本目前计划在 4 月下旬发布。

导致 FESCo 改变主意的似乎有若干个因素，首先是提案支持者的不断要求。在这个讨论进行的同时，FESCo 批准了另一个构建选项的改变（设置_FORTIFY_SOURCE=3 以增加安全性）。这一个改动也有性能上的损失 (虽然不清楚会损失多少)，它获得了批准，而 frame pointer 却没有，这被一些人认为是双重标准。同时也修改了该提案，避免 Python （这是性能代价最大的地方）使用 frame pointer。所有这些，似乎都足以说服大多数 FESCo 成员来支持这个想法。

可以想象，并非所有参加讨论的人都有同样的观点。有人抱怨这个新的 ticket 的通知时间太短，而且新 ticket 是在假期中开启的，参加就的 ticket 讨论的人也没有得到这个新 ticket 的通知。Vitaly Zaitsev 说，提案被退回 "是因为大公司对结果不满意"，并称这是一个不好的先例；Kofler 称这个过程是 "故意操纵的"。Fedora 领导人 Matthew Miller 对这一说法提出异议，但也确实承认本可以做得更好：

我同意你之前的帖子，这个 ticket 的宣传不够好，没有足够的通知，也没有足够的时间。我当然也被吓了一跳，而且我之前一直特别关注这个问题。[但是，我不认为它是出于恶意的，不是 "故意操纵" 这种说法所暗示的那种。我完全看不出这一点。我看到的是对推进已经花了很长时间的事情的兴奋和兴趣，以及迫在眉睫的实际上的 deadline。

第二次投票时间仓促，似乎是为了能在即将到来的大规模 rebuild 中能及时得到结果。显然，在从源头 rebuild 整个发行版之前而不是之后做出这样的改动，是合理的做法。但即使是一些能理解这一点的曾经参与了深入讨论的人，也觉得这个过程不太合理。

FESCo 仍有时间来重新审视（再次）这个决定，如果有必要的话，但这似乎不是这么个情况。正如 FESCo 成员 Zbigniew Jędrzejewski-Szmek 所指出的，大部分的讨论已经转移到如何来处理这个改动的一些技术细节上。因此，Fedora 38 可能会比它的前辈们性能差一点，但希望在未来的版本中，这一变化带来的性能改进可以足以弥补这一损失。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～