Messages in this thread |  | | | Date | Thu, 16 Mar 2000 11:09:55 +0000 (GMT) | | From | James Sutherland <> | | Subject | Re: 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/
|  |