From owner-freebsd-hackers Wed Sep 22 13: 9:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 3DD6E15513 for ; Wed, 22 Sep 1999 13:08:27 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id NAA27893; Wed, 22 Sep 1999 13:04:35 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id MAA01909; Wed, 22 Sep 1999 12:51:27 -0700 Received: from softweyr.com (dyn4.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA28578; Wed, 22 Sep 99 13:04:19 PDT Message-Id: <37E93642.9BC40EBF@softweyr.com> Date: Wed, 22 Sep 1999 14:04:18 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Nate Williams Cc: David Scheidt , Alfred Perlstein , Chuck Robey , "Daniel C. Sobral" , Ivan , Matthew Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: Out of swap handling and X lockups in 3.2R References: <199909221727.LAA14290@mt.sri.com> <199909221848.MAA14800@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > > > 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. Perhaps keeping track of the most recently memory-hungry process and killing is, so we get the one that is currently asking for the most pages, or making the most allocation requests? (The two are not necessarily the same). -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message