From owner-freebsd-current Tue May 8 9:42:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by hub.freebsd.org (Postfix) with ESMTP id 5290A37B423 for ; Tue, 8 May 2001 09:42:20 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (pool0302.cvx21-bradley.dialup.earthlink.net [209.179.193.47]) by hall.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA28913; Tue, 8 May 2001 12:41:25 -0400 (EDT) Message-ID: <3AF821C9.113680F1@mindspring.com> Date: Tue, 08 May 2001 09:41:45 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dennis Glatting Cc: Dag-Erling Smorgrav , Kris Kennaway , freebsd-stable@frebsd.org, freebsd-current@FreeBSD.ORG Subject: Re: pgm to kill 4.3 via vm References: <20010507112937.V47835-100000@btw.plaintalk.bellevue.wa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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