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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:18 EST