Date: Tue, 08 May 2001 09:41:45 -0700 From: Terry Lambert <tlambert2@mindspring.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: <3AF821C9.113680F1@mindspring.com> References: <20010507112937.V47835-100000@btw.plaintalk.bellevue.wa.us>
next in thread | previous in thread | raw e-mail | index | archive | help
Dennis Glatting wrote: > > What is memory exhaustion? > > Uh, when I perform a malloc() and get a NULL back? I > dunno, what do you call that? Hitting an administratively enforced resource limitation. > Why would it kill random processes as opposed to the > offending process? The offending process is the first process that causes a copy-on-write or similar fault, that results in needing to allocate a backing page for it as a result of the trap handler. When you are out of memory, the requesting program can't be satisfied, and so it gets a segmentation violation for an access to a non-existant page. Typically, this will be the first program to request more resources, after hitting the resource starvation point. A number of operating systems will allow programs to be parked "precious". In AIX, this is done by establishing a signal handler for the resource starvation condition; programs without the handler "just die". Programs with the handler are permitted to shut down gracefully. A "precious" program, such as "init" or the swapper, etc., just ignore the signal, and reestablish the handler (if they suffer from SVR3 signal semantics, and can't do it automatically). Various attempts to proactively kill off "resource pigs" have had limited historical success (generally, these are your most precious processes). Other common approaches are to support the "sticky bit" on executables, which causes their pages to be loaded into core, and wired down, so that they can never hit an overcommit barrier and get themselves terminated; similarly, there are OS's which permit a command to be run to ensure that resource reservations exist for a process' resource limits, as set by the system. This tends to "waste" resources, since programs rarely need all of the resources they could possibly ever need. The formal name for this last approach is called "The Banker's Algorithm"; search for that phrase, in conjunction with the name of its author, Djikstra, and you will find _a lot_ of information on overcommit architectures. > Regardless, the code shouldn't be crashing the kernel. Agreed. -- Terry 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?3AF821C9.113680F1>