From owner-freebsd-hackers@FreeBSD.ORG Fri May 22 07:33:59 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 E7B1D106564A for ; Fri, 22 May 2009 07:33:59 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D697A8FC1F for ; Fri, 22 May 2009 07:33:59 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id C4C821A3C40; Fri, 22 May 2009 00:33:59 -0700 (PDT) Date: Fri, 22 May 2009 00:33:59 -0700 From: Alfred Perlstein To: Yuri Message-ID: <20090522073359.GJ67847@elvis.mu.org> References: <4A14F58F.8000801@rawbw.com> <4A1594DA.2010707@rawbw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A1594DA.2010707@rawbw.com> User-Agent: Mutt/1.4.2.3i Cc: Nate Eldredge , 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 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 07:34:00 -0000 * Yuri [090521 10:52] 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. vfork, however that's not sufficient for many scenarios. > Are there any other than fork (and mmap/sbrk) situations that would > overcommit? sysv shm? maybe more. -- - Alfred Perlstein