fork() was a 1970s trick to swap a program to disk — and Linux is finally trying to move past it

The kernel's quiet campaign against fork()

LWN's article (June 5, 2026) walks through several efforts to move Linux past fork() + exec(). Li Chen's "spawn template" patch — caching executable info via spawn_template_create() / spawn_template_spawn() for repeated launches — delivered only about 2% and was effectively rejected. The favored direction is Christian Brauner's: create an empty process through a pidfd, then configure it with new declarative pidfd_config()-style syscalls (modeled on fsconfig()), enabling a native, in-kernel posix_spawn().

The article is a clean technical survey. The thread is where the history and the production pain live.

Why fork() exists at all (it's not elegance)

"it was done that way so that you could launch a program that was too big to fit in memory with the parent program. The original implementation worked by swapping out the forking program to disk on a fork() call." — John Nagle (of Nagle's algorithm)

That reframes the whole debate. fork() is celebrated as a beautiful primitive; it began as a workaround for tiny memory.

The production cost: copy-on-write still copies the page tables

"while fork() doesn't copy the memory, it still needs to copy the page table. For a process holding tens of GBs of RAM, fork() can take a long time … On an m2.xlarge using ~25GB of RAM, fork() took 5.67 seconds." — a commenter citing a classic Redis benchmark

Copy-on-write avoids duplicating data, but the page-table cost scales with how much memory you map — which is why a fat Redis instance can stall for seconds on a fork.

But is performance even the right argument?

A PostgreSQL committer cautioned that the speed case is weaker than it looks:

"It is somewhat interesting that the most widely used 'big' OS that doesn't use fork, i.e. Windows, has dog slow process creation … I agree that there should be non-fork primitives, I'm just not that sure that performance is the best argument." — Andres Freund, PostgreSQL committer

The better argument, another commenter noted, is design: in a world without fork, the APIs would simply take a target pid and configure a process from outside — which is precisely how Fuchsia works, and precisely where Brauner's pidfd-config sketch points. The case against fork() isn't that it's slow. It's that it was always a clever answer to a problem we no longer have.