Date: Wed, 22 Sep 1999 10:31:54 -0700 (PDT) From: Alfred Perlstein <bright@wintelcom.net> To: Chuck Robey <chuckr@mat.net> Cc: "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: <Pine.BSF.4.05.9909221024370.6368-100000@fw.wintelcom.net> In-Reply-To: <Pine.BSF.4.10.9909221227080.312-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Sep 1999, Chuck Robey wrote: > On Wed, 22 Sep 1999, Alfred Perlstein wrote: > > > Terry Lambert brought up an interesting thought from AIX (I think), > > instead of killing a process, it just sleeps the requesting process > > until the situation alleviates itself. Of course this can wind up > > wedging an entire system, it would probably be advisable to then > > revert to killing when more than a threshold of processes go into > > a vmwait sleep. > > Seeing as the reason for killing is because you're out of system > resources, and you need to free up some in order to go on, and sleeping > the process isn't going to free up the resources needed, I don't see how > this'll help things. > > 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. 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. 3) other processes may exit, this would free the memory needed to continue. 4) the operator could enable swap on an additional device giving more backing for things to continue. don't forget the clause about killing after putting a threshold of active processes to sleep. -Alfred 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?Pine.BSF.4.05.9909221024370.6368-100000>