From owner-freebsd-hackers Wed Sep 22 10:29:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 1D164157CE for ; Wed, 22 Sep 1999 10:29:04 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id LAA23378; Wed, 22 Sep 1999 11:27:57 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA14290; Wed, 22 Sep 1999 11:27:56 -0600 Date: Wed, 22 Sep 1999 11:27:56 -0600 Message-Id: <199909221727.LAA14290@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alfred Perlstein Cc: Chuck Robey , "Daniel C. Sobral" , Ivan , Matthew Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: Out of swap handling and X lockups in 3.2R In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What kind of resources are there that both cause loss of swap AND are > > freed up by sleeping a process? > > four things i can think of: > > 1) Along with 'SIGDANGER' it allows the system to fix itself. That's another issue. Don't mix sleeping processes with SIGDANGER, they are independant of one another. There's no mention of SIGDANGER, just of pu > 2) Allow the operator to determine which program to kill, maybe the > 'hog' is actually something that needs to run to completion and > by shutting down other systems it would survive. The operator can't kill anything, since the system would be unusable at that point, being out of resources and all. His shell wouldn't even run. > 3) other processes may exit, this would free the memory needed to > continue. Maybe, and then again, maybe not. A program is requesting memory, so putting other processes to sleep *keeps* them from freeing up memory. > 4) the operator could enable swap on an additional device giving > more backing for things to continue. See above. There are no resources available for anything to run, so the system must do *SOMETHING*. (Yes, this is a problem with memory-overcommit, but them's the breaks. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message