From owner-freebsd-hackers@FreeBSD.ORG Thu May 21 16:00:37 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 D4DA210656C0 for ; Thu, 21 May 2009 16:00:37 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id B3BB88FC0A for ; Thu, 21 May 2009 16:00:37 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n4LG0bo07233; Thu, 21 May 2009 09:00:37 -0700 (PDT) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n4LG0bO22110; Thu, 21 May 2009 09:00:37 -0700 (PDT) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Thu, 21 May 2009 09:00:37 -0700 (PDT) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: perryh@pluto.rain.com In-Reply-To: <4a150b7b.kwnuIl++HgdJdRWU%perryh@pluto.rain.com> Message-ID: References: <4A14F58F.8000801@rawbw.com> <4a150b7b.kwnuIl++HgdJdRWU%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: neldredge@math.ucsd.edu, yuri@rawbw.com, 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: Thu, 21 May 2009 16:00:38 -0000 On Thu, 21 May 2009, perryh@pluto.rain.com wrote: > Nate Eldredge wrote: >> 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. True. When I said "a system with 1GB of memory", I should have said "a system with 1 GB of physical memory + swap". -- Nate Eldredge neldredge@math.ucsd.edu