4 ms·

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

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.

sweetjuly 2y ago
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.
- toast0 2y ago
  > 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)
cperciva 2y ago
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.
- PeterWhittaker 2y ago
  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....

sweetjuly 2y ago

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.

toast0 2y ago
> 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)

cperciva 2y ago

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.

PeterWhittaker 2y ago
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....