The "too small to fail" memory-allocation rule

Posted Dec 24, 2014 9:54 UTC (Wed) by epa (subscriber, #39769)
In reply to: The "too small to fail" memory-allocation rule by roc
Parent article: The "too small to fail" memory-allocation rule

This is true. But the manipulation of file descriptors shouldn't require a complete copy of the parent process's memory. It would be handy if you could fork passing a buffer of memory and a function pointer. The child process will be given a copy of that buffer and will jump to the function given. Then you have some flexibility in what you can do before exec() but you can still be frugal in memory usage without relying on overcommit.

The "too small to fail" memory-allocation rule

Posted Dec 25, 2014 18:44 UTC (Thu) by quotemstr (subscriber, #45331) [Link]

> The child process will be given a copy of that buffer and will jump to the function given

vfork does what you want. The "child" shares memory with the parent until it calls exec, so you avoid not only the commit charge catastrophe of copy-on-write fork, but also gain a significant performance boost from not having to copy the page tables.

Re: shouldn't require a complete copy of the parent process's memory

Posted Dec 25, 2014 22:18 UTC (Thu) by ldo (guest, #40946) [Link] (1 responses)

That issue was solved a long time ago, which is why the vfork(2) hack is obsolete nowadays.

Re: shouldn't require a complete copy of the parent process's memory

Posted Dec 26, 2014 7:33 UTC (Fri) by epa (subscriber, #39769) [Link]

Sorry what issue are you referring to? The conjecture so far is that there is a problem, since a forked process gets a copy of its parent's address space, which requires either reserving enough memory (RAM or swap) to provide that, or else overcommitting and crossing your fingers (with OOM killer for when you get it wrong). It is true that copy-on-write means the kernel doesn't have to copy all the pages straight away, but that is just a time saving; it doesn't resolve the underlying issue of needing overcommit.

vfork() doesn't make a copy of the address space and so doesn't require either over-caution or over-committing. But it has other limitations.