OpenSUSE 开发人员继续讨论 x86_64 微架构功能级别

在即将到来的 openSUSE/SUSE Adaptable Linux Platform (ALP) 之前，是否要提高 Linux 操作系统所需的 x86_64 微架构特性级别以及使用更新的 x86_64 指令集扩展而不必强制执行的选项有哪些？收紧 CPU 要求/消除旧硬件支持。

正如我在 3 月初所写的那样，ALP 工作一直在考虑提高 x86_64 CPU 要求，并可能达到可能需要启用 AVX 的 CPU 的 x86-64-v3 功能级别。

三周前，在openSUSE 的这个问题跟踪器中报告了：

我刚刚收到确认，ALP 概念验证将在 2022 年 9 月/10 月启用 x86_64-v3。

SUSE 发布经理 Lubos Kocman 在那张票中继续评论说，SUSE ALP 可能会针对 x86_64-v3，但 openSUSE 可能最终会针对 x86_64-v2：

openSUSE ALP 仍在 [正在讨论中]，因为我们可以决定重新构建二进制文件或重新使用来自 SUSE 的二进制文件（这将是缩小 Leap Gap 的方式）。

如果我们决定重建，我的偏好是在“openSUSE ALP”中选择 -v2。我们在之前的社区 WG 会议上基本​​上讨论过相同的内容。

同时，在 openSUSE Factory 邮件列表上发生了围绕 x86_64 微架构特性级别的讨论。在这个邮件列表线程中，最初提出使用 openSUSE Factory 的 x86-64-v2 目标，这将要求 x86_64 CPU 支持一些附加功能，如 SSE4.2 和 POPCNT，但不需要 AVX 或 FMA 和 BMI。

该邮件列表线程还提出了有关 x86_64 微架构特性级别的当前问题，即它们是相当随意的集合，目前不能很好地集成到包管理解决方案等中。因为最终如果多个特性级别可能会工作得最好可以同时支持，理想情况下只为性能最敏感和最流行的软件包提供多个构建，其中使用较新的 x86_64 指令集扩展证明非常有益，而不是重建整个存档。

然后导致了这个 RPM 讨论票上游可能重新处理架构的处理方式，但还没有暂定的代码或可靠的建议。很高兴看到 RPM 和其他包管理软件更好地拥抱 x86_64 功能级别，以允许更健壮的包处理，特别是在包的子集可能可用并且作为包元数据的一部分能够有效地传达任何CPU 功能要求。

就 ALP 要求的提高而言，今年晚些时候 SUSE ALP 的概念验证似乎确实将针对 x86_64-v3，而在 openSUSE 方面，无论他们的目标是 v2 还是 v3，似乎还没有确定下来。这伴随着对其他​​ Linux 发行版的更广泛讨论（重新）评估他们的 x86_64 基线，并希望通过包管理器等在上游带来更多的处理改进。