Review request for 5049299 (original) (raw)
Martin Buchholz martinrb at google.com
Sat May 23 18:12:15 UTC 2009
- Previous message: Review request for 5049299
- Next message: Review request for 5049299
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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_ _>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 >> posixspawn() 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090523/bd22dd4f/attachment.html>
- Previous message: Review request for 5049299
- Next message: Review request for 5049299
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]