Linux 移除 MMX，瞄准最后的奔腾时代 RAID 优化
Linux 开发者正准备移除内核中最后的 Intel MMX 优化，为始于 1997 年奔腾处理器的一个篇章画上句号。Linux 移除 MMX 的提案针对特定存储计算，同时保留现有的软件回退方案。其核心取舍很直接：维护者需要维护的遗留代码更少，但极老旧系统可能需要付出性能代价。
MMX 是 Intel 用于处理打包数据的指令扩展，曾帮助软件加速多媒体及其他重复性计算。内核中剩余的实现服务于软件 RAID，即由操作系统控制将多块硬盘组合在一起。这些实现如今面临退役，因为通用替代方案已经能够完成相同工作。
预计目标版本是 Linux 7.5，预计将在 2027 年推出，但这仍只是发布预期，而非已完成的主线合并。对于受影响硬件的所有者而言，两者的区别很重要。这项提案改变的是特定存储计算的运行方式；它本身并不能证明每一台奔腾时代计算机都能运行未来的内核。
Linux 移除 MMX 涉及的不止一项 XOR 例程
该提案移除的是一小组遗留 RAID 实现，而不是禁用它们所加速的存储功能。
Eric Biggers 于 2026 年 10 月 25 日提交了这一系列补丁。其 MMX 退役提案包含三个补丁，涵盖 XOR、RAID6 和处理器功能检查。提交的改动涉及七个文件，新增 12 行、删除 837 行。
XOR 是一种按位组合数值的运算，有助于计算校验信息，即用于重建丢失数据的冗余信息。RAID6 是一种可容忍两块硬盘故障的存储布局，所需计算超出基本 XOR。因此，将整个系列视为删除了一项 XOR 例程，会低估其范围。
这一区别也避免了对标题作出夸大解读。移除优化实现会改变可用的执行路径；移除 RAID 支持则会消除一项存储能力。提交的提案描述的是前者，受影响的处理器将使用现有的通用代码。
Phoronix 报道称，这项工作已进入 Andrew Morton 的 MM 开发树，并将 Linux 7.5 定为可能的目标版本。其 内核 MMX 报道将该发布目标表述为预期。截至 11 月 9 日，对于围绕这项改动作规划的读者而言，这是恰当的措辞。
开发树表明这项工作正朝着整合推进，但并不意味着拟定的发布目标已成定局。审查、整合决策以及后续修订，仍可能影响最终进入内核的内容。
对于通过怀旧标题了解 Linux 移除 MMX 详解的读者，在回顾历史前，应先留意这一状态差别。已得到验证的事件是：一个清理系列已经提交，并据报道进入开发树。未来事件则是：它预计将进入主线版本。
实际边界同样重要。该系列涉及内核内部的实现，也就是操作系统的核心。它并未描述对应用程序使用 MMX 指令的一般性禁止，也没有宣告 Intel 处理器将停止识别这些指令。
这一边界改变了“一个时代的终结”的含义。内核将完成对自身 MMX 专用优化工作的退役。更广泛的软件生态，包括历史应用程序和被保存的操作系统，则有其独立的生命周期。
对维护者而言，该提案提供了简化代码中一个遗留角落的明确机会。对用户而言，它提出了一个更具体的问题：他们的机器如今是否会选择这些实现之一。这一问题直接引向硬件要求。
受影响系统处于不同的指令集门槛之下
关键分界线是处理器能力和工作负载，而不只是计算机是否带有 Pentium 标识。
Biggers 的 XOR 移除补丁指出，受影响路径面向不支持 SSE 的旧式 32 位处理器。SSE，即 Streaming SIMD Extensions，是用于同时处理多个数据元素的较晚期指令扩展。该补丁还将相关使用范围限定为实际运行 RAID 阵列的系统。
RAID6 补丁划定了不同边界：不支持 SSE2 的处理器，SSE2 是该指令家族中的后续扩展。其 RAID6 实现改动还移除了一个名为 sse1.c 的文件。Biggers 解释说，该实现仍使用 MMX 计算，并辅以 SSE 内存操作。
这一文件名颇具启发性。快速浏览可能会让人以为，该系列在移除 MMX 的同时也删除了一个独立的现代替代方案。但补丁说明指出，这是另一个围绕旧机制构建的实现。
对于评估 Intel MMX 性能影响的人而言，这些不同门槛很重要。处理器支持 SSE，并不能自动确定它是否受到该系列每一部分的影响。最终相关的比较取决于所选实现及所涉及的 RAID 计算。
设想一位爱好者在一台保存完好的 Pentium II 存储机器上运行受支持的内核配置。如果其阵列使用某个即将退役的实现，实际变化将涉及计算性能。回退方案的存在意味着，拟议的代码移除不会自动令这项计算消失。
再设想一位开发者在当代工作站上阅读同一标题。仅凭 MMX 指令扩展的年代，几乎无法说明该工作站所选择的存储实现。真正有用的证据是它实际的处理器能力和内核行为。
这些示例说明的是受影响范围，而非已测得的结果。已审阅材料并未提供仍在使用这些即将退役路径的活跃机器清单。因此，它无法支持对受影响用户数量作出精确估计。
真正需要作出决策的人，是将旧处理器能力与相关存储工作负载结合使用的运营者。他们需要确认升级是否会改变所选实现，以及由此带来的任何性能下降是否重要。
发行版维护者也面临相关的沟通任务。其内核配置、软件包可用性和处理器要求，仍与此次优化清理相互独立。用户需要了解这些细节，才能判断未来版本是否可作为保留硬件的升级选项。
因此，这项维护取舍影响的是一个狭窄的技术受众，但他们可能有很具体的需求。影响范围小并不代表没有影响，而是意味着应基于实际硬件和工作负载证据作出响应，而不是基于一个熟悉处理器名称带来的情感分量。
通用代码在保留功能的同时减少特殊情况
该提案将保留一项功能，与保留该功能的每一种历史实现区分开来。
标量回退方案，即不使用即将退役的 MMX 实现来处理数值的普通代码，让维护者可以作出这种选择。Biggers 将现有回退方案描述为经过充分测试。这是作者在移除专用路径同时保留功能的明确依据。
这句话应当放在恰当的范围内理解。它支持该提案关于连续性的论证，但并不是针对每一台受影响机器发布的性能基准。输出正确与速度相当是不同的属性。
若将其视为实现之间的选择，维护逻辑就更容易理解。当专用代码服务于用户或带来有用性能时，它可以证明自身存在的合理性。它的持续存在也会增加相关代码变更时审查者必须理解的内容。
通用代码提供了维护行为的共享位置。这并不意味着每一种专用实现都没有必要，而是提高了保留旧实现所需的证据标准：应当存在值得保留的实际收益。
这正是 Linux 移除 MMX 比一次历史纪念更有意思的地方。该项目正在权衡一条残存的性能路径，与继续维护它所带来的复杂性。可用替代方案的存在，让删除成为可能，但并不意味着这一决定没有代价。
第三个补丁将这种简化延伸至处理器功能检查，这些检查会根据可用硬件能力选择合适实现。Biggers 提议移除冗余的前提检查，并避免对相同功能进行重复检查。提交的代码保留了较新的实现，包括 SSE2 和 AVX2 路径。
AVX2 是更晚期的向量指令扩展，代表着在一次操作中处理多个数值的另一种方式。相比品牌竞争，它的存在更清晰地说明了技术比较。问题在于，哪一种实现适合处理器，并且仍值得维护。
Intel 的名称在历史中占据主导地位，因为它推出了 MMX。但实际维护决策关乎受支持的处理器功能，而非厂商品牌。比较历史上的 Intel 和 AMD 产品，无法解决某一特定内核实现是否仍值得保留的问题。
同样的逻辑也说明，为何需要谨慎解读代码行数减少。更少的行数描述的是源代码改动的规模，并不直接衡量存储速度提升、缺陷减少，或维护工时的具体下降。
因此，清理工作的最强理由是结构性的。共享回退方案保留了计算能力，而该系列移除了面向更旧能力范围的实现。性能主张则需要更多证据。
从这个角度看，Linux 移除 MMX 详解讲述的是围绕一项既有能力缩小实现负担的故事。内核可以继续完成一项工作，同时淘汰一种历史性的完成方式。这种平衡是否合理，部分取决于仍在使用它的用户。
MMX 的长期退役反映了维护取舍的变化
历史里程碑确实存在，但 MMX 的发布时间并不能衡量每一项被删除实现的年代或价值。
Intel 于 1997 年 1 月 8 日推出搭载 MMX 技术的 Pentium 处理器。其当时的 Pentium MMX 发布公告强调图形、视频和音频。一项围绕更丰富个人电脑媒体进行营销的技术，最终在内核存储计算中延续了下来。
这段历史解释了为何该提案吸引了存储开发领域之外的关注。MMX 是一项显眼的消费级功能，与个人计算中一个易于辨识的时期相关联。它最后的内核优化带有象征意义，这是普通清理工作很少获得的关注。
这种象征意义不应掩盖实际时间线。指令扩展可以早于使用它的代码。将其称为 1997 年技术的退役是准确的；但若假定每一行被移除的源代码都可追溯至 1997 年，则需要另行提供证据。
该提案也延续了此前的移除工作。Biggers 指出，之前的一次提交已移除了用于内存函数的 MMX 优化，其中包括 memcpy()、copy_page() 和 clear_page()。这些函数用于复制数据或初始化内存，与仍保留的 RAID 工作无关。
此前的退役改变了当前事件的解读框架。这是一轮更为聚焦的清理工作的收尾，而非突然决定驱逐一项被广泛使用的技术。在其他优化工作消失后，RAID 成为了内核中一个孤立的使用场景。
一项历史优化可能会逐步失去最初的存在理由。硬件不断变化，替代实现陆续出现，而使用最旧路径的用户群体也愈发难以确定。在这一过渡期间，代码仍然可以保持可用。
这带来了一个反复出现的维护问题：对于实际受众尚不明确的一条路径，项目应投入多少持续关注？当相应能力在其他地方仍然存在时，删除是一种答案。当用户能够证明其具有实际收益时，保留代码则是另一种答案。
这两种立场都不意味着应轻视旧硬件。保存工作与维护一款当前的通用内核，有着不同的目标。即使某种历史行为已不足以支撑专门的上游实现，爱好者仍可能重视复现这种行为。
反过来也是如此。怀旧并不能证明专用代码仍有活跃用户、持续测试或有意义的性能优势。这些都是技术问题，应由技术证据来回答。
更广泛的启示在于兼容性的边界。保留一种算法可用、保留针对特定处理器的优化，以及支持一台完整机器，是三种不同的承诺。项目可以改变其中一项，同时让其他项继续受各自要求约束。
对开发者而言，这是软件如何老化而非单纯失效的一个有益例子。一项优化可以从必不可少变为可选，再变得难以证明其合理性。它的退役反映的是维护取舍的变化，而非对硬件历史重要性的评判。
缺失的证据是受影响硬件上的实测性能
保留的后备实现提供了继续运行的途径，但并不保证性能保持不变。
现有的补丁说明解释了 Biggers 为何认为这些专用代码已经过时。但其中并未提供受影响机器在变更前后运行代表性存储工作负载的实测对比。因此，实际代价仍未得到解决。
这一缺口应限制两个方向上的断言。现在就宣称每个受影响系统都会明显变慢还为时过早。同样，现在就保证没人会察觉到变化也为时过早。
Intel MMX 的性能影响取决于实际操作中时间消耗在哪里。当处理是限制因素时，较慢的计算所造成的影响，与其他组件占主导地位时并不相同。仅凭该提案，无法确定某一台具体机器的这种平衡。
孤立的计算测试能回答一个有用的问题：在受控条件下，旧实现与其替代实现相比表现如何。存储工作负载则能回答另一个问题：这种差异是否会改变运维人员实际执行的工作。
这些结果不应被视为可以互换。计算吞吐量上的可见差异，并不会自动转化为应用性能上的等量差异。同样，一项可接受的日常工作负载可能会忽略一项不那么频繁、却对其所有者重要的操作。
对于一套被保存下来的存储系统，维护活动可能与日常访问同样重要。运维人员可能关心恢复工作、持续写入，或在执行其他任务时的处理器可用性。这些是建议的评估领域，而非该系列已经证实的性能退化。
因此，最有力的反对意见应来自受影响配置上可复现的结果。这类证据能够表明专用途径仍具有实际价值。它会给审阅者提供比“还有多少旧机器存在”这类假设更具体的依据。
最有力的支持则应结合持续正确性与相关硬件上的可接受表现。这将强化共享实现能够满足剩余需求的论点。再强调一次，提案本身的存在不能代替这些观察结果。
兼容性方面的说法也需要类似的克制。移除这些优化文件并不能证明已改变已存储阵列的格式。它同样不能保证每一台旧系统都能启动未来的内核。
用户必须评估完整的升级环境，包括发行版要求和自身的硬件配置。一项狭义的源代码变更无法回答机器未来支持情况的所有问题。将其表述为能够回答这些问题，会混淆彼此独立的决策。
这里同样没有依据去宣传广泛的安全性改进。减少专用代码或许能简化审查，但提交的理由并未指出此次删除修复了任何漏洞。除非有额外证据支持，否则维护收益应仍被表述为维护收益。
因此，负责任的解读应当保持克制。该系列提供了一种可信的方法，可在保留计算能力的同时减少遗留复杂性。剩余的争论关乎被移除加速功能的价值，以及判断该价值所需的证据。
关注集成、后备实现测试与发行版交付
接下来值得关注的是可观察的里程碑：进入主线、在受影响系统上测试，以及通过实际内核软件包交付。
首先，关注该系列是否进入主线内核，以及由哪个版本包含它。报道仍称 Linux 7.5 是预期目标。确认合并将强化与特定版本相关的叙述，并为下游审阅者提供明确的变更依据。
修订、延迟或撤回都会改变这一判断。更广泛的提案仍会被记录在案，但预期的发布时间需要更新。读者不应把开发树报告转化为无条件的发行说明。
确切的合并版本同样重要。即使整体方向得以保留，审查也可能改变范围或实现细节。跟踪获接受的变更，比无限期依赖最初提交，更能为兼容性分析提供坚实基础。
其次，关注真正使用这些即将退役路径的硬件所产生的正确性与性能结果。在无关的新型处理器上进行测试，无法判定受影响遗留系统的实际体验。相关对比需要匹配的配置和明确的工作负载。
一份可信的报告应区分成功运行与令人满意的速度。它还应说明测量了什么，以及变更前是否选择了旧实现。缺少这一背景，结果可能准确，却与所讨论的取舍无关。
可接受的结果将强化通用代码能够满足剩余需求的论点。具有实际运行后果的可复现性能退化则会削弱这一论点。无论结果如何，都会以证据替代假设，从而改善讨论。
第三，关注发行版交付。上游版本发布并不能说明用户选择的发行版何时会打包该内核，或是否会支持他们的机器。软件包配置和处理器要求仍是实际升级决策的一部分。
对于维护旧系统的人来说，有意义的里程碑是获得一个适配完整环境的可用内核。在此之前，该提案是有关规划的信息，而非立即更换硬件的指令。
这些观察也让历史叙事保持适当的比例。此次退役值得关注，因为它为内核优化中一个可辨识的章节画上句号。它的技术重要性将取决于最终合并的内容、剩余路径的表现，以及哪些人会遇到这一变化。
对于工程团队而言，记录并保留这些区别，可以避免一则标题演变为缺乏依据的兼容性假设。在评估升级时，可搜索的知识库可以关联已接受的补丁、本地配置和测试结果。
如果你维护受影响的硬件，应从实际运行的配置及其需要执行的存储工作开始。在测试包含该变更的内核之前，记录所选用的实现。对照反映自身工作负载的结果，并将正确性与速度分开评估。如果你维护的是较新的系统，应跟踪已接受的补丁，而不要把每一次提及 MMX 都视为兼容性警告。Linux MMX 的移除最适合作为一项已有文档记录的维护决策来理解，其收益与代价应与可观察的行为相联系。在决定这一退役对你的机器意味着什么之前，请跟踪合并进展、查看相关测试报告，并检查发行版的要求。
