超越 fork() + exec()：Linux 进程创建机制的演进与反思

背景

自 Unix 诞生之初，fork() 和 exec() 便是进程导向系统调用的两大核心支柱。fork() 负责创建一个父进程的副本作为子进程，而 exec() 则用新程序替换当前进程的执行上下文。在 Linux 内核中，这两个系统调用分别对应为 clone() 和 execve()，尽管名称不同，但其核心功能保持一致。

尽管这种进程创建模型在历史上具有其优雅之处，但也存在明显的局限性。fork() 是一个相对昂贵的系统调用，因为它必须复制整个进程的状态（包括内存）。虽然多年来人们对其进行了诸多优化，但 fork 本质上仍然是一项高成本操作。更糟糕的是，fork() 调用后往往紧跟一个 exec()，这会立即丢弃刚刚为子进程精心复制的所有内存。尽管历史上曾出现过如 vfork() 等针对此模式的优化尝试，但该模式的整体开销依然高于其理论最低值。

近期，Li Chen 提出了一项在内核中添加“生成模板”（spawn templates）的提案，旨在优化这一经典模式。虽然该提案以当前形式未被接受，但它为未来新的进程创建原语指明了方向。

核心内容

Li Chen 的补丁集采取了一种有趣的策略来优化 fork() 和 exec() 模式，其重点在于那些反复启动运行相同可执行文件的场景。例如，一个程序可能需要多次运行 Git 以获取仓库内容信息。在这种情况下，程序可以建立一个模板来加速这些调用，将设置成本分摊到多次操作中。

生成模板机制

模板的创建通过新的系统调用 spawn_template_create() 实现：

struct spawn_template_create_args { 
    __aligned_u64 flags; 
    __s32 execfd; 
    __u32 exec_flags; 
    __aligned_u64 filename; 
    /* 部分字段省略 */ 
}; 

int spawn_template_create(struct spawn_template_create_args *args, size_t args_size);

该调用返回一个文件描述符，代表该可执行文件的模板。模板源可以是文件描述符（execfd）或绝对路径（filename），二者选其一。内核会打开指定的文件并缓存大量信息，以便未来能更快地运行该文件。

实例化配置

虽然应用程序可能多次运行同一可执行文件，但每次调用的细节各不相同。具体的调用细节需放入 spawn_template_spawn_args 结构中：

struct spawn_template_spawn_args { 
    __aligned_u64 flags; 
    __aligned_u64 pidfd; 
    __aligned_u64 argv; 
    __aligned_u64 envp; 
    __aligned_u64 actions; 
    __aligned_u64 actions_len; 
    __aligned_u64 reserved[4]; 
};

• argv：指向传递给程序的参数列表。
• envp：指向程序的环境变量。
• actions：用于传递文件描述符和信号处理的更改。它是一个指向 spawn_template_action 数组的指针。

spawn_template_action 结构允许执行特定操作，例如关闭文件描述符、复制文件描述符、打开文件、更改工作目录或更改信号处理。例如，若要在子进程中关闭文件描述符 4，相关结构体的 type 设为 SPAWN_TEMPLATE_ACTION_CLOSE，fd 设为 4。

执行与性能

填充好 spawn_template_spawn_args 结构后，可通过以下调用运行新进程：

int spawn_template_spawn(int template_fd, struct spawn_template_spawn_args *args, int args_size);

内部而言，该调用遵循接近正常 fork()/exec() 的路径。Li Chen 强调，执行新文件时应用的所有正常检查均保持不变。然而，模板中的缓存信息使整个过程比之前更快。根据覆盖信（cover letter）中提供的基准测试结果，性能提升了约 2%。虽然这一数字看似不大，但对于符合预期模式的应用程序而言，这可能具有实际意义。

社区反馈与替代方案

该工作收到了 Mateusz Guzik 的详细审查。他指出：“这个问题让我深感关切，我也一直在思考它。整个 fork + exec 习语是糟糕的，需要被淘汰。” Guzik 认为补丁集的关注点有些奇怪，因为它未触及 fork() 部分，而这正是主要成本所在。他建议优化工作应致力于消除 fork()，提出“创建一个纯净的进程才是正途”，而非复制当前进程。

Christian Brauner 对这一目标持支持态度，认为“为 exec 构建一个 builder API 并不疯狂”。但他建议新的 API 应建立在现有的 pidfd 抽象之上。具体来说，他提出在 pidfd_open() 中创建一个选项以生成一个空进程，随后通过一系列对新的 pidfd_config() 系统调用来配置该进程（设置环境、执行镜像等）。pidfd_config() 在概念上类似于 fsconfig()。

Brauner 强调，新接口的一个重要目标是支持在用户空间实现 posix_spawn()。posix_spawn() 非常适合替代 fork()/exec() 模式；如果有一个原生实现（不像当前实现那样在底层隐藏 fork() 和 exec()），开发者可能会更欢迎。

Li Chen 同意 Brauner 勾勒出的 API 框架更好，并表示未来的工作将朝这个方向进行。因此，Linux 内核中将不会引入“生成模板”，但如果 Li Chen 的未来工作取得成果，Linux 最终可能会获得一个真正的 posix_spawn() 实现。

关键要点

• 性能瓶颈：传统的 fork() + exec() 模式存在固有低效，fork() 复制整个进程状态成本高，且随后 exec() 往往丢弃大部分复制的数据。
• Li Chen 的提案：引入“生成模板”（spawn templates），通过缓存可执行文件的公共信息来加速重复启动同一程序的场景。
• 性能提升有限：基准测试显示该优化仅带来约 2% 的性能提升，虽不显著，但对特定高频调用场景有意义。
• 社区批评：Mateusz Guzik 指出该方案未解决 fork() 本身的高成本问题，主张直接创建“纯净进程”而非复制。
• 更优路径：Christian Brauner 建议基于 pidfd 抽象构建新的 API（如 pidfd_config()），旨在支持用户空间原生实现 posix_spawn()。
• 最终结果：Li Chen 的“生成模板”提案未被合并，但社区共识指向了更彻底的 posix_spawn() 原生实现作为未来方向。

意义与影响

这篇报道揭示了 Linux 内核在进程管理这一基础领域面临的长期挑战。尽管 fork() 和 exec() 是 Unix 哲学的基石，但其性能开销在现代高并发、微服务化或频繁启动子进程的应用场景中日益凸显。

Li Chen 的尝试虽然未被采纳，但它引发了内核开发者对现有机制的深刻反思。Mateusz Guzik 和 Christian Brauner 的反馈表明，社区倾向于一种更根本的解决方案：即不再修补 fork()，而是通过 pidfd 等现代抽象机制，提供一种无需复制父进程即可创建和配置子进程的原语。

这一讨论的最终指向是 posix_spawn() 的原生支持。如果 Linux 内核未来能提供一个真正高效、无需隐藏底层 fork() 细节的 posix_spawn() 实现，将极大简化应用程序的开发模型，并显著提升系统整体效率。这标志着 Linux 进程创建机制可能从“复制-修改”范式向“构建-配置”范式的历史性转变。