From owner-freebsd-hackers@FreeBSD.ORG  Thu May 21 08:21:50 2009
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
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 85E24106564A
	for <freebsd-hackers@freebsd.org>; Thu, 21 May 2009 08:21:50 +0000 (UTC)
	(envelope-from perryh@pluto.rain.com)
Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34])
	by mx1.freebsd.org (Postfix) with ESMTP id 5E66D8FC13
	for <freebsd-hackers@freebsd.org>; Thu, 21 May 2009 08:21:50 +0000 (UTC)
	(envelope-from perryh@pluto.rain.com)
Received: from agora.rdrop.com (66@localhost [127.0.0.1])
	by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id n4L8Lnst050356
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 21 May 2009 01:21:49 -0700 (PDT)
	(envelope-from perryh@pluto.rain.com)
Received: (from uucp@localhost)
	by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id n4L8Lnfx050355; 
	Thu, 21 May 2009 01:21:49 -0700 (PDT)
Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407)
	id AA01437; Thu, 21 May 09 01:06:49 PDT
Date: Thu, 21 May 2009 01:06:19 -0700
From: perryh@pluto.rain.com
To: yuri@rawbw.com, neldredge@math.ucsd.edu
Message-Id: <4a150b7b.kwnuIl++HgdJdRWU%perryh@pluto.rain.com>
References: <4A14F58F.8000801@rawbw.com>
	<Pine.GSO.4.64.0905202344420.1483@zeno.ucsd.edu>
In-Reply-To: <Pine.GSO.4.64.0905202344420.1483@zeno.ucsd.edu>
User-Agent: nail 11.25 7/29/05
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 21 May 2009 08:21:50 -0000

Nate Eldredge <neldredge@math.ucsd.edu> wrote:
> For instance, consider the following program.
<snip>
> this happens most of the time with fork() ...

It may be worthwhile to point out that one extremely common case is
the shell itself.  Even /bin/sh is large; csh (the default FreeBSD
shell) is quite a bit larger and bash larger yet.  The case of "big
program forks, and the child process execs a small program" arises
almost every time a shell command (other than a built-in) is executed.

> With overcommit, we pretend to give the child a writable private
> copy of the buffer, in hopes that it won't actually use more of it
> than we can fulfill with physical memory.

I am about 99% sure that the issue involves virtual memory, not
physical, at least in the fork/exec case.  The incidence of such
events under any particular system load scenario can be reduced or
eliminated simply by adding swap space.