Florian Wemer [email protected] Fri Jul 10 17：30：09 GMT 2020大多数Linux发行版仍然基于基于AMD K8的原始x86-64基准进行编译(除了3D Now！部件，以实现英特尔EM64T兼容性)。有人试图在Glibc动态链接器中使用现有的基于AT_Platform的加载机制，以实现对优化库的选择。但Glibc中的通用选择机制是有问题的：动态加载器<；https://sourceware.org/pipermail/libc-alpha/2020-May/113757.html>；We中的hwcaps子目录选择也存在一个问题，即Glibc版本的hwcaps子目录选择不同于GCC版本的hwcaps=haswell(可能还有其他编译器)：hwcaps子目录选择平台的定义与GCC<；https://sourceware.org/bugzilla/show_bug.cgi?id=24080>；不一致。而且选择标准并不是人们所期望的：ePEC和其他当前的AMDCPU没有选择平台子目录<；https://sourceware.org/bugzilla/show_bug.cgi?id=23249>；Since基于hwcaps的选择无论采用哪种架构都不能很好地工作(即使在内核向Glibc提供数据的情况下也是如此)，我研究了一种新机制，它不存在与旧机制相关的问题：[Patch 00/30]rfc：ELF：Glibc-hwcaps support<；[Patch 00/30]RFC：ELF：Glibc-hwcaps support<；[Patch 00/30]rfc：ELF：Glibc-hwcaps support<；Https://sourceware.org/pipermail/libc-alpha/2020-June/115250.html>；(Don'；t需要注意的是，这些补丁没有经过审查；我们正忙于准备Glibc 2.32版本，而这些更改并不会改变Glibc ABI本身，因此它们没有立即优先考虑的事项。我不太相信这些变化的一个版本将会出现在glibc2.33中，我希望将它们移植到Fedora 33、Fedora 32和Red HatEnterprise Linux 8.4中。Debian也是，但我从来没有在那里做过任何喜欢的事情，所以我不知道补丁是否会被接受。)对于IBM POWER和Z来说，这应该可以很好地工作，那里的芯片版本有明显的进展(至少在纸面上--虚拟化可能会有点模糊)。但是，对于x86，我们没有那么明确的微体系结构版本的进展。这不仅是AMD/英特尔竞争的结果，也是由于同一家芯片供应商之间持续的产品差异化。我认为我们广泛地需要这些级别，原因如下：*在Glibc中选择单个CPU特性(类似于旧的hwcaps机制)存在可伸缩性问题，特别是对于LD_LIBRARY_PATH处理。*开发人员需要关于有用的优化目标的指导。我认为限制选择是有价值的，因为“如果您总共能够测试三个构建，那么这些就是您应该构建的东西”。*glibc和编译器应该在他们对级别的定义上保持一致，这样开发人员就可以使用-march=选项来构建由glibc识别的特定级别。这就是为什么我认为应该在psABI附录中介绍这些级别的原因。*如果平台由于libc/内核/虚拟机管理程序/硬件升级而升级到新版本，则这些级别的优先顺序可以避免退回到K8基准。我用单个字母来表示它们，但我希望这个提议的具体实现将使用类似于“x86-100”、“x86-101”的名称，就像上面提到的Glibc补丁一样。(但我们可以讨论其他方法。)我查看了红帽实验室的各种机器，并与英特尔和AMD的工程师讨论了这一点，但这个具体的建议是基于我自己对情况的分析。我排除了与密码和缓存管理相关的CPU功能，包括硬件事务内存和CPU计时。我假设随着时间的推移，我们会看到其中一些功能被固件或内核禁用。对于密码代码，我希望优化实现的本地化选择是可行的，因为这样的代码往往是孤立的块，每次运行几十个周期，而不是被编译器分散到各处。我们之前讨论过不在后面的级别发出VZEROUPPER，但我不认为这是有益的，因为ABI没有直接保存的向量寄存器，所以它只能用于本地。更改用户空间中的文件系统基数会造成太多中断，因此主要好处是rdfsbase的编码更紧密，这看起来非常精简。这里没有讨论调优决策。我认为我们可以从实现之间在这方面的一些差异中获益；这不应该影响正确性。32位支持也是另一回事。*级别ACMPXCHG16B、LAHF/SAHF、POPCNT、SSE3、SSE4.1、SSE4.2、SSSE3这比K8基准高出一级，相当于主线CPU型号约2008至2011年。它也是即时消息