Link

2024-07-07 10:28| 来源: 网络整理| 查看: 265

参考Link-time optimization for the kernel —— 2012

内核开发人员总是在寻找让系统运行更快的方法，在优化方面投入了大量的工作。所以当一个不需要重写关键性能相关的代码就可以让内核变得更快的机会出现时，很自然的，吸引了很多人的兴趣。新版本gcc支持的Link time optimizations LTO功能是不是这样的一个机会还有待验证，但是Andi Kleen决定去找出来。

LTO背后的理念是：通过检查编译完单独文件后的整个程序，探索可能出现的任何优化机会。最重要的机会是小函数的inlining。编译器也可以更积极的检测和消除为使用的代码和数据。当源文件编译时，LTO将编译器中间表示（GIMPLE，与机器无关的中间表示）放入到目标文件中。实际LTO阶段加载所有的GIMPLE代码到一个单一核心的映像中，重写进一步优化的目标代码。 LTO功能最开始在GCC4.5上出现，但是在4.7上才变得可用。但是它仍然有一些限制，其中一个就是：所有涉及的对象文件都必须使用相同的命令行选项来编译。下面将讲到，这个限制对于kernel来说是一个问题。 Andi的LTO补丁包含了74个改动，不是一个小的改动，而且是侵入性的。但是大部分改动具有相同的基本范围：确保编译器知道特定的symbols（即使没有用到）；所以LTO阶段将不会优化它们。举个例子来说，导出到模块的symbols可能没有任何的调用者，但是他们需要保留下来，应为可能有module后来加载进来。为此，Andi第一个补丁定义了一个新属性（__visible）用来标记这些symbols，大部分其他的补丁都是致力于将__visible属性加入到需要的地方。此外，当使用LTO构建Kernel时还会出现一小部分的固定或特定问题。当长参数列表的函数在LTO阶段inlined的话，看可能会导致一些参数被破坏，为了阻止这种情况发生，将这些函数标记为noinline。Andi抱怨“我希望有一个通用的方式来做这件事，这就像一个定时炸弹问题”。他承认LTO可能会引入新的优化相关的bug，找到所有的这些bug是一个难题。接着说所有文件需要使用相同的选项来编译的问题。当前kernel不是这样构建的，不同的部分使用不同的选项。一些地方，可禁用特定的优化，一些地方则禁用LTO。使用新版本gcc是必要的，同时需要安装一个development版本的binutils。使用LTO，即使是一个小的kernel构建，也需要4GB的内存，allyesconfig更多，需要9GB。实际上，大部分人不想用LTO。因为LTO可能会引入微妙的bugs、优化相关的误解，甚至LTO功能本身也可能存在问题，所以在使用LTO来构建产品的Kernel之前需要广泛的测试。鉴于以上挑战，补丁包的尺寸和维护的负担，人们可能会怀疑，使用LTO是否值得。这就涉及到了加入LTO，kernel究竟会有多快？现在还没有得到准确的数据，LTO补丁是新的，同时还有许多问题需要处理。Andi报告"hackbench" benchmark表明提升了5%，一些网络benchmarks提升了18%。这几个数字是粗糙的，但是足以鼓励进一步的工作，Andi也希望GCC提升LTO的实现。 Andi还建议，从长期来看，通过消除将inline函数放到include文件的需要，LTO可以帮助提升kernel代码的质量。所有的这些都只是该补丁的早期开发阶段，不太可能merge到近期的kernel中，即使作为一个试验性的功能也不可能。长期来看，它可以让kernel更快。此外，kernel中使用LTO会帮驱动GCC实现，进一步所有项目都会受益。因此，值得关注此事。

总结：

1. LTO实验性太强，它不是完全可靠，缺少大量实验。 2. Patch只针对X86平台，且对编译器版本有一定的要求。 3. 主要目的是提升CPU速度，而不是删减尺寸。 4. 编译时间变长

【本文地址】

公司简介

联系我们