From owner-freebsd-current Mon May 7 9:55:59 2001 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id A7BB737B42C for ; Mon, 7 May 2001 09:55:56 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f47GtiK61081; Mon, 7 May 2001 09:55:44 -0700 (PDT) (envelope-from dillon) Date: Mon, 7 May 2001 09:55:44 -0700 (PDT) From: Matt Dillon Message-Id: <200105071655.f47GtiK61081@earth.backplane.com> To: Dennis Glatting Cc: Dag-Erling Smorgrav , Kris Kennaway , , Subject: Re: pgm to kill 4.3 via vm References: <20010507074503.Y24943-100000@btw.plaintalk.bellevue.wa.us> <01050708414400.13646@kwijibo> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : 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