From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 06:25:48 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1795A106566C for ; Fri, 22 May 2009 06:25:48 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 630E08FC12 for ; Fri, 22 May 2009 06:25:46 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n4M6PiBW092816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 22 May 2009 15:55:44 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org, yuri@rawbw.com Date: Fri, 22 May 2009 15:55:40 +0930 User-Agent: KMail/1.9.10 References: <4A14F58F.8000801@rawbw.com> <4A1594DA.2010707@rawbw.com> In-Reply-To: <4A1594DA.2010707@rawbw.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1803539.heUJSqalCy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200905221555.42775.doconnor@gsoft.com.au> X-Spam-Score: -3.508 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Nate Eldredge Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 06:25:48 -0000 --nextPart1803539.heUJSqalCy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 22 May 2009, Yuri wrote: > Nate Eldredge wrote: > > Suppose we run this program on a machine with just over 1 GB of > > memory. The fork() should give the child a private "copy" of the 1 > > GB buffer, by setting it to copy-on-write. In principle, after the > > fork(), the child might want to rewrite the buffer, which would > > require an additional 1GB to be available for the child's copy. So > > under a conservative allocation policy, the kernel would have to > > reserve that extra 1 GB at the time of the fork(). Since it can't > > do that on our hypothetical 1+ GB machine, the fork() must fail, > > and the program won't work. > > I don't have strong opinion for or against "memory overcommit". But I > can imagine one could argue that fork with intent of exec is a faulty > scenario that is a relict from the past. It can be replaced by some > atomic method that would spawn the child without ovecommitting. If all you are going to do is call execve() then use vfork(). That explicitly does not copy the parent's address space. Also your example is odd, if you have a program using 1Gb (RAM + swap)=20 and you want to start another (in any way) then that is going to be=20 impossible. If you had a 750Mb process that forked and the child only modified 250Mb=20 you'd be all right because the other pages would be copies. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1803539.heUJSqalCy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKFkVm5ZPcIHs/zowRAq2jAJ4ukljsV0PaIASBrO2YZOWvBumGMQCdHGP/ dHLr3G3LFnwNE9pJIqngrkM= =Q6yy -----END PGP SIGNATURE----- --nextPart1803539.heUJSqalCy--