Date: Wed, 22 Sep 1999 12:02:00 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.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>, freebsd-hackers@FreeBSD.ORG Subject: Re: Out of swap handling and X lockups in 3.2R Message-ID: <199909221902.MAA16905@apollo.backplane.com> References: <Pine.BSF.4.05.9909221153500.6368-100000@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:> (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.
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 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.
-Matt
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?199909221902.MAA16905>