Linus 批评英特尔的 LAM 代码，拒绝将其合并到内核
英特尔希望将其 LAM（Linear Address Masking ：线性地址掩码） 功能合并到 Linux 6.2，但该功能被 Linus 批评了一番，并拒绝了该合并。
英特尔线性地址掩码 (LAM) 允许软件将 64 位线性地址的未转换地址位用于元数据，线性地址使用 48 位（4 级分页）或 57 位（5 级分页），而 LAM 允许将 64 位线性地址的剩余空间用于元数据。
简而言之，英特尔 LAM 在使用用户空间地址的未翻译地址位，因此它可用于用户空间内存清理和标记等元数据的多种用途，它的本质上类似于 AMD 的高位地址忽略“UAI”（Upper Address Ignore ）以及 Arm 的顶部字节忽略“TBI”（Top-Bits-Ignore）功能。
英特尔在 2020 年初次对外展示 LAM，从那以后一直致力于 Linux 内核支持。11月中旬，英特尔工程师为 Linux 6.2 的 x86/mm 分支提交了大量补丁，希望将该功能代码合并到内核中。
然而，LAM 随即遭受了 Linus 的猛烈批评，不仅是内核实现代码，Linus 甚至连“LAM” 这个名称都不满意：
现在要求英特尔将这个 LAM 功能称为“Top-Bits-Ignore” （TBI） ，会不会有些太晚了？
...
整个 LAM 功能不是特定于 mm ，它可以轻松影响每个线程。
想象一下，有一个设置，其中一些线程使用标记指针，而一些线程不使用。例如，地址的高位可能包含一个仅在虚拟机中使用的标签，甚至可以让“本机”模式使用完整的地址空间，并将其自身及私有数据虚拟地放在高位。
再想象一下，使用虚拟地址掩码不仅能实现内存清理器，还能实现一种真实的分离功能（例如，JITed 代码可能基本上只能访问较低的位，而 JITter 本身可以看到整个地址空间）。
也许这不是 LAM 在 x86 上的工作方式，但它对 untagged_addr() 的更改并不是 x86 特定的。所以我真的认为这是完全错误的，除了命名之外， 它全都是一些无效的假设。事实上，这个特定于 mm 的 LAM 功能，最后只会成为代码中一个活跃的 Bug ，即使在 x86-64 上也是如此。
所以我真的认为 LAM 是一个根本性的设计错误，虽然我把它拉出来并解决了琐碎的冲突，但我又把它拉了下来，因为它的设计是错误的。
Linux 内核邮件列表讨论了对英特尔的 LAM 的 Linux 实现方式的设计更改。但 Linus 认为英特尔 LAM 代码还没有为 Linux 做好准备，因此最终没有合并代码。英特尔已提交新的 x86/mm pull ，但删除了 LAM 代码。英特尔 Linux 工程师将重新编写 LAM 代码，为 Linux 6.3 做准备。
