Review request for 5049299
martinrb at google.com
Sat May 23 18:12:15 UTC 2009
On Sat, May 23, 2009 at 01:28, Andrew Haley <aph at redhat.com> wrote:
> Martin Buchholz wrote:
> > On Fri, May 22, 2009 at 15:13, Michael McMahon <Michael.McMahon at sun.com
> >> Martin,
> >> Thanks. Great comments. Just a few comments of my own
> >> on a couple of points.
> >> 1. Linux won't benefit from this change as much as solaris, since due to
> >> its
> >> "memory overcommit" architecture, it doesn't suffer from the problem
> >> much)
> >> in the first place (though memory overcommit causes some problems of
> >> own).
> >> Nevertheless, maybe it could simplify the code a bit if we use
> >> posix_spawn() on Linux
> >> as well. So, I will look into that.
> > Any company running server farms (think "Sun" or "Google")
> > would like to "bin-pack" as many processes as possible onto them,
> > and transient doubling of process size is a big problem in such an
> > environment. Think of this as a
> > saving-the-planet-from-global-warning feature.
> But those running Linux won't benefit from such a change because
> on Linux there is no transient doubling of process size: all that happens
> is that the page table entries in the new process are mapped copy on write.
> The extra pages count towards the overcommit limit, but that's wholly
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the core-libs-dev