Date: 16 Jul 1999 14:02:14 +0300 From: Ville-Pertti Keinonen <will@iki.fi> To: julian@whistle.com (Julian Elischer) Cc: hackers@freebsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <86k8s0n9hl.fsf@not.demophon.com> In-Reply-To: julian@whistle.com's message of "14 Jul 1999 21:10:44 %2B0300" References: <199907141755.LAA05231@orthanc.ab.ca> <Pine.BSF.3.95.990714110627.5088E-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
julian@whistle.com (Julian Elischer) writes: > If you wanted to fix this, you could add a patch to malloc that touched > every page that it handed to the application. (and trapped sig11s) How would you expect that to work? Several misunderstandings seem to be common regarding this issue (most not directed at you): - malloc almost never fails with NULL. This is not true, if resource limits are set properly, any one program using huge amounts of memory is going to hit them long before swap space is exhausted. - The program currently trying to get the page is the one that is killed. - Actually paging in all memory is going to protect a program from getting killed. This is going to make it *more likely* for it to be killed. - Not overcommitting doesn't consume huge amounts of reserve space unless programs do something special. A rough sum of memory usage can be computed by summing up all of the process VSZs plus your stack limit times the number of processes. How many of you would be willing to configure that much swap space? If you really wanted to run without overcommit, you'd only run statically linked binaries and set your stack limits to small values. This could be desirable for some (but not general-purpose) systems, an option for doing this wouldn't be entirely bogus. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86k8s0n9hl.fsf>