Date: Wed, 22 Sep 1999 11:27:56 -0600 From: Nate Williams <nate@mt.sri.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: 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 Message-ID: <199909221727.LAA14290@mt.sri.com> In-Reply-To: <Pine.BSF.4.05.9909221024370.6368-100000@fw.wintelcom.net> References: <Pine.BSF.4.10.9909221227080.312-100000@picnic.mat.net> <Pine.BSF.4.05.9909221024370.6368-100000@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909221727.LAA14290>