Date: Mon, 7 May 2001 09:55:44 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Dennis Glatting <dennis.glatting@software-munitions.com> Cc: Dag-Erling Smorgrav <des@ofug.org>, Kris Kennaway <kris@obsecurity.org>, <freebsd-stable@frebsd.org>, <freebsd-current@FreeBSD.ORG> Subject: Re: pgm to kill 4.3 via vm Message-ID: <200105071655.f47GtiK61081@earth.backplane.com> References: <20010507074503.Y24943-100000@btw.plaintalk.bellevue.wa.us> <xzpy9s9mbyl.fsf@flood.ping.uio.no> <01050708414400.13646@kwijibo>
next in thread | previous in thread | raw e-mail | index | archive | help
: The malloc() and calloc() functions return a pointer to
: the allocated memory if successful; otherwise a NULL
: pointer is returned and errno is set to ENOMEM.
:
:I assert memory exhaustion is would return "unsuccessful" on the
:malloc() call, no?
malloc() returns NULL if the process datasize resource limit is exceeded,
as set by the setrlimit() system call, 'limit' csh/tcsh command, or
'ulimit' sh/bash command. You are required to set this (and other)
limits to reasonable values for your machine... the machine has no clue
as to when you want things to start to fail because often systems become
unusable long before they run out of swap. By default the machine tries
to accomodate everything. malloc() does not return NULL if the machine
itself runs out of VM.
mmap() currently bypasses the datasize resource limit... it does not
reserve VM space from same area as malloc(). We've known this for a
while and know we need to add another setrlimit type to handle it.
If you use mmap() to allocate huge amounts of anonymous memory and
you don't have the swap to back it up, you can crash the machine.
Theoretically the system is supposed to start killing large processes
when memory + swap gets full, but that code does not appear to be working
as well as it should at the moment.
This argument rears its head about once a year and usually turns into a
huge flame war. It's one of those things that you can make quite
excellent theoretical arguments for, which look great on paper, but the
reality is so incompatible with the theory (read: the theoretical
solutions break more people then it fixes) that the smarter people
huck the theory into the dumpster and stick with the reality.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105071655.f47GtiK61081>