Date: Wed, 22 Sep 1999 12:53:29 -0700 (PDT) From: Alfred Perlstein <bright@wintelcom.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Nate Williams <nate@mt.sri.com>, Chuck Robey <chuckr@mat.net>, "Daniel C. Sobral" <dcs@newsguy.com>, Ivan <Ivan.Djelic@prism.uvsq.fr>, freebsd-hackers@FreeBSD.ORG Subject: Re: Out of swap handling and X lockups in 3.2R Message-ID: <Pine.BSF.4.05.9909221245320.6368-100000@fw.wintelcom.net> In-Reply-To: <199909221902.MAA16905@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Sep 1999, Matthew Dillon wrote: > :> (Matt) > :> How about this - add an 'importance' resource. The lower the number, > :> the more likely the process will be killed if the system runs out of > :> resources. We would also make fork automatically decrement the number > :> by one in the child. > :> > :> The default would be 1000. The sysadmin could then use login.conf to > :> lower the hard limit for particular users or user classes, and of course > :> set a specific limit for particular root-run processes (though, in general, > :> the daemons will be protected because their children will be more likely > :> to be killed then they will). > :> > :> The system would use the importance resource to modify its search for > :> processes to kill - perhaps use it as a divisor. Or the system could use > :> it absolutely then kill the biggest process of the N processes sitting > :> at the lowest importance level. > :> > :> This also solves the sysad-cant-login problem and the user-is-naughty > :> problem. > : > :I knew it would be Matt to come up with something like this, it sounds > :great. > : > :Maybe a limit to how many kills a process can score, meaning that if > :one process seems to be killing a lot of programs the system may come > :down and kill it? > : > :This along with sleeping would allow someone to log in, (with a high > :importance) and probably su and still be able to manage to save the > :box. > : > :maybe? :) > : > :-Alfred > > Well, the problem with a score like that is that we don't necessarily > know which processes are responsible for depriving the system of its > resources, so we don't know who to score against. Chances are that the allocator is the one depriving, it will more than likely be the one requiring more memory... In the case of a root process that has racked up many kills to satisfy its memory requirments it would be important to recognize that and kill it. The kills factor should be reduced in after a certain amount of time so long running processes do not exhaust resonable amounts of kills just by living for a long time. > Reading Nate's most recent email I have to agree that whatever we come > up with, it needs to be (A) relatively simple and deterministic, and > (B) work out of the box. I think my 'importance' resource limit idea > covers both bases quite well. I agree. > I don't like the sleep idea at all, because it has the same problem > of not really knowing which process to sleep in the first place. The > use of an importance resource may not be able to immediately > target the exact process causing the problem, but it should do the job > well enough to avoid putting the system into a state that would require a > reboot to get all the right things working again. And it certainly can > do the job well enough to allow a sysad to login. The importance of the sleep is so that the admin can see what has gone wrong before the OS guesses at it. We reserve processes for root, why not a few pages? I think killing, even when done somewhat intellegently as the only solution seems to be the New Jersey approach. On the other hand, until I grok more of the code I'll gladly take what I can get. :) One more last minute idea, with the exception of root processes, what about trying to kill processes with the same uid? -Alfred > Matthew Dillon > <dillon@backplane.com> 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.9909221245320.6368-100000>