Date: Thu, 24 Jul 2003 18:08:38 -0500 (CDT) From: Brent Casavant <b.j.casavant@ieee.org> To: freebsd-stable@freebsd.org Subject: Re: malloc does not return null when out of memory Message-ID: <Pine.BSO.4.44.0307241800450.8755-100000@skyline.tdkt.org> In-Reply-To: <20030724163012.E295C37B49D@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[hopefully I didn't mess up the attribution, replying to a digest sucks] On Thu, 24 Jul 2003, Jamie Bowden wrote: > On Wed, 23 Jul 2003, Don Lewis wrote: > > > On 23 Jul, Brooks Davis wrote: > > > > No there isn't. Overcommit is a fundamental design feature of the BSD > > > VM. If you don't like it, find an OS that doesn't do it. The only one > > > I can think of off the top of my head in Irix where I've found it to be > > > a serious pain in the ass. > > Irix allows for use of what it calls 'vswap' as well, which is just a file > that lives on a normal filesystem that the system can fall back on when > actual RAM and swap are exhausted. It allows for extremely large commits > on memory limited systems while guaranteeing that it has somewhere to page > out to if necessary. The poster above may not like Irix, but I do. > There's a lot of good stuff in there, but SGI aren't the best at telling > people it exists and how to use it. Almost. Having actually worked on the IRIX VM system, and on vswap issues in particular... Don is correct in that IRIX doesn't overcommit. But that is only the default swap configuration. The amount of "vswap" you add to the system is the amount by which the VM system is allowed to overcommit total memory (real swap + RAM). If the system is overcommitted and runs into a genuine memory outage, then processes will start to be killed (hopefully intelligently). In particular "vswap" is not a file that lives in the normal filesystem that gets swapped to. The somewhat ugly syntax for adding vswap means that vswap does get configured along with a normal swap area (file or device), but vswap itself has no backing store. Clear as mud? BTW, I've found that more people are confused by memory overcommitting than the abscence thereof. I've found an analogy to overbooking airline flights to be useful in clarifying the situation. That said, I think overcommitting is the right thing to do for typical system usage, but that this behavior should be configurable for the unusual cases. Brent -- Brent Casavant http://www.angeltread.org/ 44.9067N 93.0558N 907F -.- -.. ..... . -- -...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSO.4.44.0307241800450.8755-100000>