子进程退出后内核复制 CoW 页面
Kernel copying CoW pages after child process exit
在Linux中,无论何时分叉一个进程,父进程的内存映射都会克隆到子进程中。实际上,出于性能原因,页面设置为 写时复制——最初它们是共享的,如果两个进程之一写入其中一个,然后他们将被克隆 (MAP_PRIVATE
).
这是获取 运行 程序状态快照的一种非常常见的机制——您执行一个 fork,这为您提供了当时进程内存的(一致的)视图时间点。
我做了一个简单的基准测试,其中有两个组件:
- 具有线程池的父进程写入数组
- 一个子进程,它有一个线程池,该线程池制作数组的快照并取消映射
在某些情况下(machine/architecture/memory placement/number 个线程/...)我能够使复制完成比线程写入数组早得多。
然而,当子进程退出时,在 htop
我仍然看到大部分 CPU 时间花在了内核中,这与它被用来处理 写时复制每当父进程写入页面时。
以我的理解,如果标记为写时复制的匿名页面被单个进程映射,则不应复制它,而应直接使用它。
如何确定这段时间确实是在复制内存?
如果我是对的,我怎样才能避免这种开销?
基准测试的核心在下面,在现代 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
}
数组大小为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时,两个数组的虚拟页都被标记为copy-on-write。子进程从 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;
}
不同的线程可能会尝试同时多次写入同一缓存行,从而导致错误共享。这可能不是什么大问题,具体取决于处理器缓存行的大小、线程数以及所有内核是否 运行 处于同一频率,因此不进行测量很难说。更好的循环形状是让每个线程的元素在数组中连续。
在Linux中,无论何时分叉一个进程,父进程的内存映射都会克隆到子进程中。实际上,出于性能原因,页面设置为 写时复制——最初它们是共享的,如果两个进程之一写入其中一个,然后他们将被克隆 (MAP_PRIVATE
).
这是获取 运行 程序状态快照的一种非常常见的机制——您执行一个 fork,这为您提供了当时进程内存的(一致的)视图时间点。
我做了一个简单的基准测试,其中有两个组件:
- 具有线程池的父进程写入数组
- 一个子进程,它有一个线程池,该线程池制作数组的快照并取消映射
在某些情况下(machine/architecture/memory placement/number 个线程/...)我能够使复制完成比线程写入数组早得多。
然而,当子进程退出时,在 htop
我仍然看到大部分 CPU 时间花在了内核中,这与它被用来处理 写时复制每当父进程写入页面时。
以我的理解,如果标记为写时复制的匿名页面被单个进程映射,则不应复制它,而应直接使用它。
如何确定这段时间确实是在复制内存?
如果我是对的,我怎样才能避免这种开销?
基准测试的核心在下面,在现代 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
}
数组大小为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时,两个数组的虚拟页都被标记为copy-on-write。子进程从 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;
}
不同的线程可能会尝试同时多次写入同一缓存行,从而导致错误共享。这可能不是什么大问题,具体取决于处理器缓存行的大小、线程数以及所有内核是否 运行 处于同一频率,因此不进行测量很难说。更好的循环形状是让每个线程的元素在数组中连续。