泰晓资讯·5月 / 第一期 / 2020

“泰晓资讯”，广泛报道 “Linux/开源” 业界资讯。欢迎广大读者投递相关资讯来源和素材，本站将进一步收集整理后发布给大家。

主动内存规整（Proactive memory compaction）

Many applications benefit significantly from the use of huge pages. However, huge-page allocations often incur a high latency or even fail under fragmented memory conditions. Proactive compaction may provide an effective solution to these problems by doing memory compaction in the background. With my proposed proactive compaction implementation, typical huge-page allocation latencies are reduced by a factor of 70-80 while incurring minimal CPU overhead.

许多应用程序都受益于使用 “巨页（huge page）”，即由多个地址连续的基本页（一般大小为 4K）组成的内存块。但是，分配 huge page 的代价可不低，特别是在内存碎片化情况下更容易导致内存分配失败。为此内核历史上提出了 “内存规整（Memory compaction）” 的解决方案，（具体可以参考泰晓科技 LWN 翻译计划组织翻译的 “LWN 368869: 内存规整（compaction）” 等文章）。严格地说这是一种 “按需内存规整（on-demand memory compaction）”，因为其实现思路是在内存分配函数的执行过程中一旦发现无法满足大块内存的分配需要才会触发规整，具体实现是唤醒 per-node 的 kcompacted 线程对内存进行整理，直到满足分配所需。这么做的效率很高，但坏处是由于会在内存分配路径中引入额外的操作，遇到突发情况需要分配大量 huge-page 时很可能导致较高的延迟。

内核社区很早就注意到了这个情况，并提出了所谓的 “主动规整（Proactive compaction）” 的想法，其核心思想和 On-demand compaction 的主要区别是 Proactive compaction 希望在后台任务中增加更多的自主判断来尝试执行更多的内存规整，而不是仅仅在进程运行过程中根据内存分配函数被调用时所传入的有限信息执行规整。而且规整操作也不是只满足当前内存分配的请求，而是根据配置或者其他实际情况会持续运行从而为后继的 huge-pages 分配预先准备更多的连续内存空间。（具体可以参考泰晓科技 LWN 翻译计划组织翻译的 “LWN 717656: 主动（proactive）内存规整（compaction）” 这篇文章）。

最近 Nitin Gupta 基于主动规整的思想提供了一个补丁实现。除了实现后台规整的逻辑外，还对使用者开放了一个可调参数：/sys/kernel/mm/compaction/proactiveness，调整值在 [0，100] 范围内，默认值为 20，使用者可以利用该可调参数确定内核在后台规整内存的积极程度。该补丁重用了现有的 per-NUMA-node 的 kcompactd 线程，这些线程会定期计算每个节点的碎片评分，并将其与根据可调参数计算出的阈值进行比较。当节点的碎片评分超过阈值的上限时，kcompactd 后台线程就会启动内存整理。规整过程将一直运行，直到节点的得分下降到阈值的下限以下或满足其他一些退出条件之一才会停止。

据 Nitin Gupta 介绍，基于其补丁的测试结果表明，其实现可以优化典型的 huge-pages 分配，使其延迟等待时间减少百分之七十到八十，同时 CPU 的开销也非常小。鉴于这些令人鼓舞的数字，该补丁有望被接受。社区专家们已经 review 了他的补丁并提出了一些改进建议。如果要正式合入内核估计还要再进行几轮迭代。

感兴趣的同学可以阅读 LWN 原文 “Proactive compaction for the kernel”。我还在网上搜到了补丁作者自己的 blog 介绍：“Linux kernel hugepage allocation latencies” 和 “Proactive Compaction”，内容更加详细。

关键词: Linux，proactive-memory-compaction

最近 LTTng 有点麻烦

Back in February, the kernel community discussed the removal of a couple of functions that could be used by loadable modules to gain access to symbols (functions and data structures) that were not meant to be available to them. That change was merged during the 5.7 merge window. This change will break a number of external modules that depended on the removed functions; since many of those modules are proprietary, this fact does not cause a great deal of anguish in the kernel community. But there are a few out-of-tree modules with GPL-compatible licenses that are also affected by this change; one of those is LTTng. Fixing LTTng may not be entirely straightforward.

在 “泰晓资讯·3月 / 第三期 / 2020” 的一篇资讯 “这个 “后门” 终于被堵上了” 中给大家介绍过：内核删除了一些函数，譬如 kallsyms_lookup_name()，以避免一些动态加载的模块可能利用这些函数来访问一些内核内部的符号（函数和数据结构）。这一改动在 5.7 合并窗口期间合入了内核主线。由于大部分此类模块都是 “专有（proprietary）”的，因此社区没什么人对此担心。但现在发现还有一些遵循 GPL 兼容许可证的模块和软件，也受到了这个改动的影响，LTTng 就是其中之一，而且大家发现要修复这个对 LTTng 的影响并不是很简单。

LTTng 用于对内核进行系统测试，其功能依赖于在内核中许多深层次的地方加上 hook，从而实现对运行中的内核进行跟踪和统计。一旦诸如 kallsyms_on_each_symbol() 此类函数被删除后，LTTng 就无法根据符号查找某些内核对象的地址，导致其大部分功能无法正常工作。这对于那些开发 LTTng 或者使用 LTTng 的人来说，肯定不是一个好消息。

为此 LTTng 的开发者提交了一个补丁来导出一些自己需要的符号。但很显然，内核开发人员是非常反对这种做法的。原因很简单，任何一个暴露出来给外部的数据结构和函数都会给内核程序员的开发自由带来一定程度的限制，因为以后试图对这些代码的修改都要获得所有外部用户的同意。

其实问题的本质在于：LTTng 目前还不是内核的一部分，内核内部的代码可以根据需要随时进行更改，由于这些接口的所有调用者都存在于同一个代码库中，所以可以同时更改掉。而 LTTng 作为一个内核之外的组件，自然不受内核社区的待见。虽然 LTTng 的一些底层代码已经合入内核了，但至少到目前为止，由于一些技术上的原因，LTTng 作为一个整体并没有完全合入。

因此，LTTng 目前似乎处于一个两难境地：无法独立于内核工作，但也无法被完全合入内核。但是，如果 LTTng 无法使用的话，会对许多用户造成严重的伤害，这对推动 Linux 或自由软件的发展可没啥好处。看来内核社区又遇到一个不小的麻烦，有关的同志请持续对此保持关注，更详细的介绍请阅读 LWN 原文 “How to unbreak LTTng”。

关键词: Linux，LTTng

好心的微软又给 Linux 带来了好东西

There are many ways to try to keep a system secure. One of those, often employed in embedded or other dedicated-purpose systems, is to try to ensure that only code that has been approved (by whoever holds that power over the system in question) can be executed. The secure boot mechanism, which is intended to keep a computer from booting anything but a trusted kernel, is one piece of this puzzle, but its protection only extends through the process of booting the kernel itself. Various mechanisms exist for protecting a system after it boots; a new option for this stage is the Integrity Policy Enforcement (IPE) security module, posted by Deven Bowers.

在 “泰晓资讯·4月 / 第二期 / 2020” 的一篇资讯 “微软宣布启动 IPE 项目，解决 Linux 系统完整性问题” 中我们给大家简单介绍了 “微软（Mircosoft）” 这家以 Windows 闻名的操作系统公司针对 Linux 推出了一个名为 “完整性策略执行（Integrity Policy Enforcement，简称 IPE）” 的安全模块（Linux Security Module）。今天在 LWN 上看到了一篇介绍这个补丁的比较详细的文章，再次介绍给大家。

我们有很多方法可以确保系统安全。安全启动机制确保在计算机启动过程中只加载受信任的内核，但这种保护仅涵盖了启动过程。系统启动后，还需要多种保护系统的机制。而来自微软的 Deven Bowers 所提交的 “完整性策略执行（Integrity Policy Enforcement，简称 IPE）” 安全模块就是专门聚焦于审核并确保系统运行过程中所执行的程序是合法而且安全的。

IPE 需要与 dm-verity 配合使用，后者是内核子系统的 Device Mapper 中的一个子模块，可对块设备进行完整性检查，具体方法是通过层次性地验证各级 hash 来校验数据是否被篡改。IPE 在 dm-verity 的基础上还提供了一套简洁的配置接口，允许管理员制定策略设定具体哪些程序可以运行。具体的语法，感兴趣的同学可以阅读原文 “The integrity policy enforcement security module” 或者该补丁自带的说明文档。

目前该补丁是否能被主线接受还不明朗，但至少 Jonathan Corbert 先生认为问题不大。

关键词: Linux，Mircosoft，IPE

联系我们

资讯内容部分来自 “LWN.net“。如果您对某些 LWN 文章感兴趣（譬如希望获得全文翻译的）请扫描二维码加微信联系我们：