Date: Wed, 22 Sep 1999 11:52:12 -0700 (PDT) From: Alfred Perlstein <bright@wintelcom.net> To: Nate Williams <nate@mt.sri.com> 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: Sleeping in low memory situations (was re: 3.3 lockups + X) Message-ID: <Pine.BSF.4.05.9909221133210.6368-100000@fw.wintelcom.net> In-Reply-To: <199909221727.LAA14290@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Sep 1999, Nate Williams wrote: > > > 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 Why not? It's much more friendly... > > 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. That's untrue, a syscall doesn't take memory, if there was a prompt already available it would be possible to issue a 'kill %job' to stop it. Not only that but perhaps reserving an amount of backing store for root may be a good idea, artificially limit the resources to several pages to enable root to actually do something in such a situation. > > 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. I didn't say putting others to sleep, I said putting the requestor to sleep. > > 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*. You're right, point 4 is bogus unless you consider reserved backing for root. When the reserved backing is used up moving to a kill would be necessary. I really hope people aren't taking this as a total solution, I just wanted to bring something up for discussion, putting the process to sleep isn't the entire answer, but mixed with other measures it could make for a nice alternative than the kill anything approach. I also know that this is somewhat flawed as I'm pretty sure that there are many places where there is no reference to the requestor, that is a problem right? The problem is that all i'm getting is reasons not to do this, I'd appreciate 2 kinds of feedback: 1) references to an implementation that tried this and failed or succeeded. 2) additional ideas on how to best implement this. (I particularly like my idea of artificially limiting non root processes.) :) We have the best minds in the world working on FreeBSD, surely we can find a suitable alternative. -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.9909221133210.6368-100000>