随着时间的推移，系统上的内存可能会变得越来越碎片化，使得难以找到连续的 RAM 块来满足持续的分配请求。在某些时候，运行中的系统可能会将内存区域压缩在一起以释放更大的块，但 Vlastimil Babka 最近指出，这种压缩不够频繁，无法避免代码在发出较大内存请求时出现延迟问题。

Vlastimil 希望创建一个新的每 CPU 守护进程，称为 kcompactd，它将作为持续的系统活动来执行内存压缩。

David Rientjes 提出的基本异议是，在所有 CPU 上创建全新的线程会带来自身的开销问题。他建议让其他每 CPU 线程之一简单地承担额外的内存压缩责任。他认为 khugepaged 守护进程是最佳候选者。

实际上，Vlastimil 已经确定 khugepaged 是一个候选者，但拒绝了它，理由是 khugepaged 仅处理 THP（透明巨页）内存用例。这些是常规内存分配之上的抽象层，因此它不会涵盖所有可能的用例，而只会涵盖处理 THP 的用户代码。

David 认为，THP 分配是大多数压缩问题发生的地方，而其他分配系统，如 SLUB 分配器（用于高效的内核分配），不是问题的一部分。

最终，David 实际上设想了两种形式的内存压缩。第一种是定期压缩，无论 RAM 的状态如何都会发生。第二种是当检测到特定的 RAM 区域过度碎片化时触发的压缩。David 认为，通过将这两种形式的内存压缩彼此分离，可以将各种功能附加到不同的现有线程上，并避免在内核中创建新的每 CPU 线程。

最终的设计在讨论中没有确定下来，但似乎没有人认为内存压缩本身是一个坏目标。问题始终是如何实现它。Mel Gorman 甚至建议，很多工作可以通过用户空间通过 SysFS 接口完成。但是，这个想法在讨论中没有被探讨，因此似乎只有技术障碍可能会阻碍某些后台内存压缩进入内核。

正如 Tal Shorer 最近指出的那样，在内核中启用 CONFIG_TRACING 选项的一个问题是，它会启用绝对所有的跟踪点，从而导致显着的性能损失。他认为，允许用户仅在其感兴趣测试的子系统上启用跟踪点更有意义。

他发布了一个补丁来做到这一点。或者更确切地说，他发布了一个补丁来放弃旧系统，并允许用户仅在 GPIO 子系统上启用跟踪点。他说，他选择 GPIO 作为测试用例。如果获得批准，他表示愿意提交其余所有子系统的补丁。

由于整体内核开发周期，他的补丁花了几个星期才完成审核。新的合并窗口已经打开，因此像 Steven Rostedt 这样通常会查看 Tal 提交内容的人，在合并窗口再次关闭之前，都太忙于处理任何新代码。

不过，一旦理清了这一点，他对 Tal 的反馈似乎大多是积极的。看起来跟踪点很快将按子系统划分，而不是内核范围。

为了允许非 root 用户编写良好的系统监控软件，Prarit Bhargava 希望以只读方式向非 root 用户公开 MSR 值。MSR 寄存器是 Intel 特有的一组寄存器，Intel 最初旨在用于其自身的调试目的，并且不保证未来的芯片组会提供相同的值。但随着时间的推移，这些寄存器似乎已经围绕调试和监控功能合并，并且 Linux 内核确实向 root 用户公开了它们。

Prarit 认为，允许只读访问将避免任何潜在的安全问题，因为用户将无法随意修改这些寄存器的实际值。但正如其他人指出的那样，MSR 寄存器的危险也存在于它们公开的内核对象和内存区域中。即使是只读访问也可能足以让怀有恶意的用户获得足够的信息来成功攻击运行中的系统。

因此，Prarit 与 Andy Lutomirski 和 Pavel Machek 合作编写了一个 PMU（性能监控单元）驱动程序，该驱动程序仅向用户公开一组经过特定白名单筛选的 MSR 数据。这样，他们就可以编写他们的系统监控软件，而不会冒着新的攻击风险，并且如果 Intel 在未来的芯片中更改了 MSR 寄存器，则这些更改需要经过审查，并且白名单需要更新，然后任何修改后的数据才能向普通用户公开。

作为这个特定问题重要性的一个例子，Len Brown 在讨论中提到，劳伦斯利弗莫尔国家实验室 非常关注 Prarit 工作的设计和结果。那里的人员想要一种安全有效的方式来访问这些 MSR 寄存器，而这项工作将提供这种方式。