c++ - 子进程退出后内核复制 CoW 页面

Question

在 Linux 中，无论何时 fork 一个进程，父进程的内存映射都会被克隆到子进程中。实际上，出于性能原因，页面被设置为写时复制——最初它们是共享的，如果两个进程之一写入其中一个，它们将随后被克隆(MAP_PRIVATE)。

这是获取正在运行的程序状态快照的一种非常常见的机制——您执行一次 fork ，这会为您提供该时间点进程内存的(一致的) View 。

我做了一个简单的基准测试，其中有两个组件:

• 具有线程池的父进程写入数组
• 一个子进程，它有一个线程池，用于制作数组快照并取消映射

在某些情况下(机器/架构/内存布局/线程数/...)我能够使复制完成的时间比线程写入数组的时间早得多。

但是，当子进程退出时，在 htop 中我仍然看到大部分 CPU 时间花在了内核上，这与它被用来处理 copy-on 是一致的-write 每当父进程写入页面时。

在我看来，如果标记为copy-on-write 的匿名页面被单个进程映射，则不应复制它，而应直接使用它。

我如何确定这确实是在复制内存上花费的时间？

如果我是对的，我该如何避免这种开销？

---

基准测试的核心在现代 C++ 中。

定义WITH_FORK启用快照；保留未定义以禁用子进程。

#include <unistd.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/wait.h>

#include <numaif.h>
#include <numa.h>

#include <algorithm>
#include <cassert>
#include <condition_variable>
#include <mutex>
#include <iomanip>
#include <iostream>
#include <cmath>
#include <numeric>
#include <thread>
#include <vector>

#define ARRAY_SIZE 1073741824 // 1GB
#define NUM_WORKERS 28
#define NUM_CHECKPOINTERS 4
#define BATCH_SIZE 2097152 // 2MB

using inttype = uint64_t;
using timepoint = std::chrono::time_point<std::chrono::high_resolution_clock>;

constexpr uint64_t NUM_ELEMS() {
  return ARRAY_SIZE / sizeof(inttype);
}

int main() {

  // allocate array
  std::array<inttype, NUM_ELEMS()> *arrayptr = new std::array<inttype, NUM_ELEMS()>();
  std::array<inttype, NUM_ELEMS()> & array = *arrayptr;

  // allocate checkpoint space
  std::array<inttype, NUM_ELEMS()> *cpptr = new std::array<inttype, NUM_ELEMS()>();
  std::array<inttype, NUM_ELEMS()> & cp = *cpptr;

  // initialize array
  std::fill(array.begin(), array.end(), 123);

#ifdef WITH_FORK
  // spawn checkpointer threads
  int pid = fork();
  if (pid == -1) {
    perror("fork");
    exit(-1);
  }

  // child process -- do checkpoint
  if (pid == 0) {
    std::array<std::thread, NUM_CHECKPOINTERS> cpthreads;
    for (size_t tid = 0; tid < NUM_CHECKPOINTERS; tid++) {
      cpthreads[tid] = std::thread([&, tid] {
        // copy array
        const size_t numBatches = ARRAY_SIZE / BATCH_SIZE;
        for (size_t i = tid; i < numBatches; i += NUM_CHECKPOINTERS) {
          void *src = reinterpret_cast<void*>(
            reinterpret_cast<intptr_t>(array.data()) + i * BATCH_SIZE);
          void *dst = reinterpret_cast<void*>(
            reinterpret_cast<intptr_t>(cp.data()) + i * BATCH_SIZE);
          memcpy(dst, src, BATCH_SIZE);
          munmap(src, BATCH_SIZE);
        }
      });
    }
    for (std::thread& thread : cpthreads) {
      thread.join();
    }
    printf("CP finished successfully! Child exiting.\n");
    exit(0);
  }
#endif  // #ifdef WITH_FORK

  // spawn worker threads
  std::array<std::thread, NUM_WORKERS> threads;
  for (size_t tid = 0; tid < NUM_WORKERS; tid++) {
    threads[tid] = std::thread([&, tid] {
      // write to array
      std::array<inttype, NUM_ELEMS()>::iterator it;
      for (it = array.begin() + tid; it < array.end(); it += NUM_WORKERS) {
        *it = tid;
      }
    });
  }

  timepoint tStart = std::chrono::high_resolution_clock::now();

#ifdef WITH_FORK
  // allow reaping child process while workers work
  std::thread childWaitThread = std::thread([&] {
    if (waitpid(pid, nullptr, 0)) {
      perror("waitpid");
    }
    timepoint tChild = std::chrono::high_resolution_clock::now();
    std::chrono::duration<double> durationChild = tChild - tStart;
    printf("reunited with child after (s): %lf\n", durationChild.count());
  });
#endif

  // wait for workers to finish
  for (std::thread& thread : threads) {
    thread.join();
  }
  timepoint tEnd = std::chrono::high_resolution_clock::now();
  std::chrono::duration<double> duration = tEnd - tStart;
  printf("duration (s): %lf\n", duration.count());

#ifdef WITH_FORK
  childWaitThread.join();
#endif
}

Answer 1

数组大小为1GB，也就是大约250K页，其中每页大小为4KB。对于这个程序，可以很容易地估计出由于写入 CoW 页面而发生的页面错误的数量。它还可以使用 Linux perf 工具进行测量。 new 运算符将数组初始化为零。所以下面一行代码:

std::array<inttype, NUM_ELEMS()> *arrayptr = new std::array<inttype, NUM_ELEMS()>();

将导致大约 250K 页面错误。同样，下面一行代码:

std::array<inttype, NUM_ELEMS()> *cpptr = new std::array<inttype, NUM_ELEMS()>();

将导致另一个 250K 页面错误。所有这些页面错误都是次要的，也就是说，它们可以在不访问磁盘驱动器的情况下得到处理。分配两个 1GB 阵列不会对具有更多物理内存的系统造成任何重大故障。

此时，已经发生了大约500K页错误(当然还会有程序其他内存访问引起的其他页错误，但可以忽略不计)。 std::fill 的执行不会导致任何小错误，但数组的虚拟页面已经映射到专用物理页面。

然后程序的执行继续到 fork 子进程并创建父进程的工作线程。自己创建子进程就足以做数组的快照了，所以真的不需要在子进程中做任何事情。事实上，当子进程被 fork 时，两个数组的虚拟页面都被标记为写时复制。子进程从 arrayptr 读取并写入 cpptr，这导致额外的 250K 小错误。父进程还写入arrayptr，这也会导致额外的 250K 小故障。因此，在子进程中制作拷贝并取消映射页面不会提高性能。相反，页面错误的数量增加了一倍，性能显着下降。

您可以使用以下命令测量次要故障和主要故障的数量:

perf stat -r 3 -e minor-faults,major-faults ./binary

默认情况下，这将计算整个流程树的次要和主要错误。 -r 3 选项告诉 perf 重复实验三次并报告平均值和标准偏差。

我还注意到线程总数为 28 + 4。最佳线程数大约等于系统上在线逻辑核心的总数。如果线程数远大于或小于该数，由于创建过多线程并在它们之间切换的开销，性能将会下降。

另一个潜在的问题可能存在于以下循环中:

for (it = array.begin() + tid; it < array.end(); it += NUM_WORKERS) {
  *it = tid;
}

不同的线程可能会尝试同时多次写入同一缓存行，从而导致错误共享。根据处理器缓存行的大小、线程数以及所有内核是否以相同频率运行，这可能不是一个重大问题，因此如果不进行测量就很难说。更好的循环形状是让每个线程的元素在数组中连续。