I did a little research.<br><br>The overcommitment policy on Linux is configurable<br><a href="http://lxr.linux.no/linux/Documentation/vm/overcommit-accounting">http://lxr.linux.no/linux/Documentation/vm/overcommit-accounting</a><br>
Of course, almost everyone will use the default "heuristic" policy,<br>and in this case the COW memory after fork() is subject to overcommit<br>accounting, which *may* cause the fork to fail.<br><a href="http://lkml.indiana.edu/hypermail/linux/kernel/0902.1/01777.html">http://lkml.indiana.edu/hypermail/linux/kernel/0902.1/01777.html</a><br>
If a solution using clone(CLONE_VM ...) can be made to work,<br>subprocess creation will be a little cheaper and significantly more reliable.<br><br>Martin<br><br><div class="gmail_quote">On Sat, May 23, 2009 at 12:09, Andrew Haley <span dir="ltr"><<a href="mailto:aph@redhat.com">aph@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Martin Buchholz wrote:<br>
<br>
> I confess to incomplete understanding of the situation on Linux, but...<br>
> I agree that the limit is artificial,<br>
> in that there is no doubling of actual  memory.<br>
> It's a monitoring problem, whether internal to the linux kernel<br>
> or perhaps some other external software "accounting" entity.<br>
> Nevertheless, I believe this limit prevents a process currently using<br>
> 75% of memory from starting a small subprocess and<br>
> expect that clone() with CLONE_VM will fix that.<br>
<br>
</div>AFAIAA that should not happen.  I'd be interested to try a test case.<br>
<font color="#888888"><br>
Andrew.<br>
</font></blockquote></div><br>