Date: Wed, 22 Sep 1999 12:44:54 -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: Re: Sleeping in low memory situations (was re: 3.3 lockups + X) Message-ID: <Pine.BSF.4.05.9909221232370.6368-100000@fw.wintelcom.net> In-Reply-To: <199909221846.MAA14760@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Sep 1999, Nate Williams wrote: > > 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. No the topic is finding a better way to handle the situation in a more intellegent manner. Nathan, if killing process randomly or even with Matt's algorithm is what you want there will really be no changing that. I'm not looking for arguments keeping the current method, i'm looking for arguments for a new method of handling this. What's needed is a softer way of doing this. > > > > 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. And that's not what I'm sticking with. > > > > 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...) bind doesn't need to run as root, niether do a lot of things out of inetd, and if they do encounter memory shortages I'm all for killing less important things. Remeber, things started up earlier have a precidence for allocation (Matt's algorithm) therefore most servers would be ok. I also like the idea of a kill count, so that if a process seems to be nuking everything in sight while chewing up memory, the OS will decided that it's out of control. > > 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..... :) It can be implemented in a self tuning manner with reasonable defaults. > > > > 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?Pine.BSF.4.05.9909221232370.6368-100000>