Review request for 5049299
martinrb at google.com
Sat May 23 18:10:34 PDT 2009
I did a little research.
The overcommitment policy on Linux is configurable
Of course, almost everyone will use the default "heuristic" policy,
and in this case the COW memory after fork() is subject to overcommit
accounting, which *may* cause the fork to fail.
If a solution using clone(CLONE_VM ...) can be made to work,
subprocess creation will be a little cheaper and significantly more
On Sat, May 23, 2009 at 12:09, Andrew Haley <aph at redhat.com> wrote:
> Martin Buchholz wrote:
> > I confess to incomplete understanding of the situation on Linux, but...
> > I agree that the limit is artificial,
> > in that there is no doubling of actual memory.
> > It's a monitoring problem, whether internal to the linux kernel
> > or perhaps some other external software "accounting" entity.
> > Nevertheless, I believe this limit prevents a process currently using
> > 75% of memory from starting a small subprocess and
> > expect that clone() with CLONE_VM will fix that.
> AFAIAA that should not happen. I'd be interested to try a test case.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the core-libs-dev