Hacker News Reader

Comment by PeterWhittaker | Hacker News Reader

But Linux doesn't clone the entire address space: it copies the page table, RO: if the child attempts to write, then it uses COW.

So if fork/clone is followed immediately by exec/execve/etc., there is minimal copying.

View on HN

Surely it also marks the parent process' pages as COW too? If only the child is RO but the parent still has RW mappings to the same physical pages, writes from the parent will be observed in the child, which is wrong for COW. You either have to copy the pages immediately (in which cases there's no COW) or you have to make all mappings to the physical page RO.

The implications of this is that even if you immediately execve in the child, you still have to pay for the cost of setting COW on the entire address space and then later faulting on every single writable page in the parent process. The performance impact might not be massive, but it's not nothing.

> You either have to copy the pages immediately (in which cases there's no COW) or you have to make all mappings to the physical page RO.

One of these enhanced fork exec calls stops the parent until the child execs. Then you don't need to touch the parent page mappings or worry about concurrency. (Although it's not ideal if the parent is threaded)

Yes, that's what said. Fork doesn't copy the data but it does copy the address space. For a large process (say, a database with multiple GB of data) that's a lot of paging tables -- many MB of them if you're using 4 kB pages.

You're resurrecting memories from the mists of time, but I seem to remember a common design pattern back in the day for cases like this was to have a persistent lightweight parent that would fork a processing child that could then request the parent perform fork-and-exec operations.

But it's been a while....

Reply on news.ycombinator.com