From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 17:52:29 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 8BBEC1065670 for ; Thu, 21 May 2009 17:52:29 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell.rawbw.com (shell.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 777D28FC1E for ; Thu, 21 May 2009 17:52:29 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from eagle.syrec.org (ppp-71-139-35-171.dsl.snfc21.pacbell.net [71.139.35.171]) (authenticated bits=0) by shell.rawbw.com (8.13.6/8.13.6) with ESMTP id n4LHqSfp051284; Thu, 21 May 2009 10:52:28 -0700 (PDT) Message-ID: <4A1594DA.2010707@rawbw.com> Date: Thu, 21 May 2009 10:52:26 -0700 From: Yuri User-Agent: Thunderbird 2.0.0.21 (X11/20090419) MIME-Version: 1.0 To: Nate Eldredge References: <4A14F58F.8000801@rawbw.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org 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 Reply-To: yuri@rawbw.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 17:52:29 -0000 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. Are there any other than fork (and mmap/sbrk) situations that would overcommit? Yuri