lkml.org 
[lkml]   [2000]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Overcomittable memory
On 15 Mar 2000, Rask Ingemann Lambertsen wrote:

> Den 13-Mar-00 14:14:19 skrev Khimenko Victor følgende om "Re: Overcomittable memory (Was: Linux 2.2.15pre12)":
> > In <1404.107T1850T4774770rask@kampsax.k-net.dk> Rask Ingemann Lambertsen
> > (rask@kampsax.k-net.dk) wrote:
>
> >> This doesn't mean that overcommit is a good idea. It just means that
> >> fork()/exec() is not a good way of launching programs. Using overcommit to
> >> cover up for fork()/exec() deficiencies is like redirecting compiler
> >> warnings to /dev/null instead of fixing the code. The symptoms become less
> >> visible but the problem remains. The problem could be solved by introducing
> >> a new system call with the ability to start an external program as a new
> >> process.
>
> > And then we should start playing stupid games with file descriptors. And
> > then you can not spawn simple process to communicate with extenal program
> > over net. And my 20 apache processes will require 800MiB of virtual memory
> > instead of 60MiB they are using now.
>
> Where on Earth did you get those ideas from?

Those 20 Apache processes each have 40Mb exclusively allocated to them.
To honour that allocation without overcommit requires 20*40 = 800Mb of VM.

> > Not every fork will end up with exec, you know.
>
> I don't think anybody said they do. I surely didn't.

The problem is, that fork() allocates memory - the same amount as the
parent process has allocated. If you want to honour this without
overcommit, you must disable COW - otherwise you've overcommitted your
memory.


James.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site