On Sat, May 23, 2009 at 01:28, Andrew Haley <a...@redhat.com> wrote: > Martin Buchholz wrote: > > On Fri, May 22, 2009 at 15:13, Michael McMahon <michael.mcma...@sun.com > >wrote: > > > >> 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 > (so > >> much) > >> in the first place (though memory overcommit causes some problems of > its > >> 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 > artifical. >
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. Martin
