From owner-freebsd-hackers  Wed Sep 22 11:49:10 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 A79B014FF0
	for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Sep 1999 11:49:08 -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 MAA24295;
	Wed, 22 Sep 1999 12:48:57 -0600 (MDT)
	(envelope-from nate@rocky.mt.sri.com)
Received: by mt.sri.com (SMI-8.6/SMI-SVR4)
	id MAA14800; Wed, 22 Sep 1999 12:48:56 -0600
Date: Wed, 22 Sep 1999 12:48:56 -0600
Message-Id: <199909221848.MAA14800@mt.sri.com>
From: Nate Williams <nate@mt.sri.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: David Scheidt <dscheidt@enteract.com>
Cc: Nate Williams <nate@mt.sri.com>,
	Alfred Perlstein <bright@wintelcom.net>,
	Chuck Robey <chuckr@mat.net>, "Daniel C. Sobral" <dcs@newsguy.com>,
	Ivan <Ivan.Djelic@prism.uvsq.fr>,
	Matthew Dillon <dillon@apollo.backplane.com>,
	freebsd-hackers@FreeBSD.ORG
Subject: Re: Out of swap handling and X lockups in 3.2R
In-Reply-To: <Pine.NEB.3.96.990922131457.26337A-100000@shell-3.enteract.com>
References: <199909221727.LAA14290@mt.sri.com>
	<Pine.NEB.3.96.990922131457.26337A-100000@shell-3.enteract.com>
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

> > Maybe, and then again, maybe not.  A program is requesting memory, so
> > putting other processes to sleep *keeps* them from freeing up memory.
> 
> The process that is trying to use memory is put to sleep.

Then this 'rogue' process is never allowed to free up any of it's
resources, hence the system is *still* out of swap, and all of the
non-offending processes must deal with the out-of-memory situation they
haven't caused, nor can they do anything about it.

So, now we have a system that just takes longer to completely die off
due to lack of resources since we've stopped the biggest offender from
getting bigger.

(Also, it turns out that often enough the process that requests the page
that drives the system over the edge is not in fact the rogue process,
thus causing the system to slowly become unusable with no way of
recovering.)

I'd much rather my system die quickly than slowly, since by dying
quickly I can get back to work much quicker instead of not getting any
work done for a long period of time.



Nate


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message