linux - 调用 mlockall() 后在同一地址重复发生小页面错误

Question

问题

在尝试减少/消除应用程序中轻微页面错误的过程中，我发现了一个令人困惑的现象；也就是说，即使我认为我已经采取了足够的措施来防止页面错误，但我反复触发写入同一地址的小页面错误。

背景

根据建议here ，我调用了 mlockall 将所有当前和 future 的页面锁定到内存中。

在我最初的用例(涉及一个相当大的数组)中，我还按照建议 here 写入每个元素(或至少写入每个页面)来预先对数据进行故障处理。 ;尽管我意识到那里的建议是针对运行带有 RT 补丁的内核的用户，但强制写入以阻止 COW/请求分页的一般想法应该仍然适用。

我原以为 mlockall 可以用来防止轻微的页面错误。虽然手册页似乎只保证不会出现重大错误，但各种其他资源(例如上面)指出它也可用于防止轻微页面错误。

内核文档似乎也表明了这一点。例如，unevictable-lru.txt和 pagemap.txt声明 mlock() 的页面是不可回收的，因此不适合回收。

尽管如此，我还是继续触发了几个小的页面错误。

例子

我创建了一个极其精简的示例来说明问题:

#include <sys/mman.h> // mlockall
#include <stdlib.h> // abort

int main(int , char **) {
  int x;

  if (mlockall(MCL_CURRENT | MCL_FUTURE)) abort();

  while (true) {
    asm volatile("" ::: "memory"); // So GCC won't optimize out the write
    x = 0x42;
  }
  return 0;
}

这里我重复写同一个地址。很容易看出(例如通过 cat/proc/[pid]/status | awk '{print $10}')我在初始化完成后很长时间内仍然存在轻微的页面错误。

运行 systemtap-doc 中包含的 pfaults.stp 脚本的修改版本*，我记录了每个页面错误的时间、触发错误的地址、触发故障的指令，是否是主要/次要，以及读/写。在启动和 mlockall 的初始错误之后，所有错误都是相同的:尝试写入 x 触发了一个小的写入错误。

连续页面错误之间的间隔显示出一种引人注目的模式。对于一次特定的运行，间隔以秒为单位:2, 4, 4, 4.8, 8.16, 13.87, 23.588, 40.104, 60, 60, 60, 60, 60, 60, 60, 60, 60, ...这似乎是(大约)指数回退，绝对上限为 1 分钟。

在独立的 CPU 上运行它没有影响；以更高的优先级运行也没有。但是，以实时优先级运行会消除页面错误。

问题

1. 这种行为是预期的吗？
   1a.如何解释时间安排？
2. 是否有可能避免这种情况？

版本

我正在运行 Ubuntu 14.04，内核 3.13.0-24-generic 和 Systemtap 版本 2.3/0.156，Debian 版本 2.3-1ubuntu1 (trusty)。使用 gcc-4.8 编译的代码没有额外的标志，尽管优化级别似乎并不重要(前提是 asm volatile 指令保留在原位；否则写入得到优化完全退出)

我很乐意提供更多详细信息(例如确切的 stap 脚本、原始输出等)，如果它们被证明是相关的话。

---

*实际上，vm.pagefault 探测器因我的内核和 systemtap 组合而被破坏，因为它引用了一个不再存在于内核的 handle_mm_fault 函数中的变量，但是修复是微不足道的)

Answer 1

@fche 提到了 Transparent Huge Pages让我走上正轨。

粗心阅读我在问题中链接到的内核文档表明 mlock 确实不会阻止内核将页面迁移到新的页面框架；事实上，有一整节专门讨论 migrating mlocked pages .因此，简单地调用 mlock() 并不能保证您不会遇到任何轻微的页面错误

有点迟了，我看到了this answer引用相同的段落并部分回答了我的问题。

内核可能移动页面的原因之一是 memory compaction ，由此内核释放了一个大的连续页面 block ，因此可以分配一个“大页面”。可以轻松禁用透明大页面；参见例如this answer .

我的特定测试用例是在 3.13 kernel 中引入的一些 NUMA 平衡变化的结果。 .

引用LWN article linked therein :

The scheduler will periodically scan through each process's address space, revoking all access permissions to the pages that are currently resident in RAM. The next time the affected process tries to access that memory, a page fault will result. The scheduler will trap that fault and restore access to the page in question...

可以通过将进程的 NUMA 策略设置为显式使用某个节点来禁用调度程序的这种行为。这可以通过在命令行中使用 numactl(例如 numactl --membind=0)或调用 libnuma 库来完成。

编辑 sysctl documentation关于 NUMA 平衡的明确说明:

If the target workload is already bound to NUMA nodes then this feature should be disabled.

这可以通过 sysctl -w kernel.numa_balancing=0

来完成

页面迁移可能还有其他原因，但这足以满足我的目的。