From owner-freebsd-hackers Wed Sep 22 10:39: 3 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 BC9F015985 for ; Wed, 22 Sep 1999 10:38:58 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA16257; Wed, 22 Sep 1999 10:38:49 -0700 (PDT) (envelope-from dillon) Date: Wed, 22 Sep 1999 10:38:49 -0700 (PDT) From: Matthew Dillon Message-Id: <199909221738.KAA16257@apollo.backplane.com> To: Nate Williams Cc: Alfred Perlstein , Chuck Robey , "Daniel C. Sobral" , Ivan , freebsd-hackers@FreeBSD.ORG Subject: Re: Out of swap handling and X lockups in 3.2R References: <199909221727.LAA14290@mt.sri.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message