Date: Wed, 22 Sep 1999 12:46:07 -0600 From: Nate Williams <nate@mt.sri.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Nate Williams <nate@mt.sri.com>, 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: Sleeping in low memory situations (was re: 3.3 lockups + X) Message-ID: <199909221846.MAA14760@mt.sri.com> In-Reply-To: <Pine.BSF.4.05.9909221133210.6368-100000@fw.wintelcom.net> References: <199909221727.LAA14290@mt.sri.com> <Pine.BSF.4.05.9909221133210.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 > > Why not? It's much more friendly... See previous conversation. For now, let's keep this conversation on track with the sleep/swap problem. > > > 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 quite. Chances are huge that the 'idle' shellprocess was swapped out, and there's no memory for it to be swapped in. Also, 'kill' requires memory to run. > 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. Stick to the topic at hand. That's another topic again, and the topic is the validity of putting processes to sleep. > > > 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. That's not what was proposed by Terry. > > > 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. Unfortunately, *most* of the processes that this effects are root processes, so this solution doesn't work in general. (Bind, sendmail, samba, inetd and it's children, etc...) > 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.) :) See Matt's recent email. Since I'm not convinced one way or the other on it, I'll let more more experienced folks comment. However, I have one problem with it, in that *configuring* a system is already way too complex. It would be nice (perhaps impossible) to have the system implement a default policy that works 'most of the time'. I understand that this 'default' policy won't work for everyone, but building software that is extremely configurable is the path that leads to hacking sendmail.cf files directly, which means that very few people understand it. The recent 'IRC' discussion was a great example of this. Unfortunately, you have to be a system expert to run the box, else you end up with a sub-standard system. Unless we (FreeBSD) have a self-tuning system that 'Does The Right Thing' for most of the folks out of the box, we're just providing another esoteric system that can blow the socks of anything else *IF* the person running it is an expert. However, as the recent WWW comparison with Linux and NT proves, if you've got experts configuring your system, chances are pretty good that you'll lose. FreeBSD's strenght up to this point is that 'out-of-the-box' it works *very* well without a lot of tuning. It would be nice to keep this feature as new problems arise. But, I'm on a soapbox, so I'll step off now..... 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?199909221846.MAA14760>