From owner-freebsd-hackers Wed Sep 22 12: 2: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C966214E0C for ; Wed, 22 Sep 1999 12:02:01 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA16905; Wed, 22 Sep 1999 12:02:00 -0700 (PDT) (envelope-from dillon) Date: Wed, 22 Sep 1999 12:02:00 -0700 (PDT) From: Matthew Dillon Message-Id: <199909221902.MAA16905@apollo.backplane.com> To: Alfred Perlstein Cc: Nate Williams , Chuck Robey , "Daniel C. Sobral" , Ivan , freebsd-hackers@FreeBSD.ORG Subject: Re: Out of swap handling and X lockups in 3.2R References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> (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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message