Date: Thu, 21 May 2009 09:00:37 -0700 (PDT) From: Nate Eldredge <neldredge@math.ucsd.edu> To: perryh@pluto.rain.com 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? Message-ID: <Pine.GSO.4.64.0905210859130.1483@zeno.ucsd.edu> In-Reply-To: <4a150b7b.kwnuIl%2B%2BHgdJdRWU%perryh@pluto.rain.com> References: <4A14F58F.8000801@rawbw.com> <Pine.GSO.4.64.0905202344420.1483@zeno.ucsd.edu> <4a150b7b.kwnuIl%2B%2BHgdJdRWU%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 21 May 2009, perryh@pluto.rain.com wrote: > Nate Eldredge <neldredge@math.ucsd.edu> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0905210859130.1483>