From owner-cvs-all Fri Mar 14 13:38:10 2003 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D62CA37B401; Fri, 14 Mar 2003 13:38:06 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFF3343FE3; Fri, 14 Mar 2003 13:38:02 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.8/8.12.7) with ESMTP id h2ELc1QA001844; Fri, 14 Mar 2003 16:38:01 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Fri, 14 Mar 2003 16:37:59 -0500 To: John Baldwin , Pawel Jakub Dawidek From: Garance A Drosihn Subject: Re: cvs commit: src/sys/vm ... SIGDANGER Cc: cvs-all@FreeBSD.org, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, David Schultz , Eivind Eklund , Juli Mallett , Poul-Henning Kamp , Mike Silbersack , "Daniel C. Sobral" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 4:05 PM -0500 3/14/03, John Baldwin wrote: >On 14-Mar-2003 Pawel Jakub Dawidek wrote: > > >> Why not choose process to kill by their priority? >> > > If we got some important processes even without uid=0 we could > > renice them to value less than 0. > >I don't think raw priority should be taken into account, but using >the nice value in the algorithm (perhaps as a weight of some sort?) >sounds like a good idea actually. nice is an existent mechanism >for SA's to mark which processes are more important than others so >it seems intuitive to seek to preserve nice -20 processes at the >expense of nice +20 processes. The problem is, 'nice' already has one specific meaning, and that meaning is *not* "Sure, go ahead and kill me!". I feel uneasy if we try to guess at which process to kill based on values which are set for unrelated and perfectly-good reasons. [I do kind-of like the idea of preserving processes with negative nice values, but I would not want to assign any special kill-meaning to nice values >= 0] Perhaps the problem people have with SIGDANGER, even though it has in fact been proven to be useful in real-life situations, is that as implemented by AIX you have to change some source code (maybe in a variety of programs) to take advantage of it. That is an interesting point, but perhaps we can solve that. How about having the default SIGDANGER signal handler do something a little more interesting than always ignoring the signal? Perhaps have the default routine check some process-specific value, and it (the default signal handler) can decide what to do based on that value. Then give a system administrator a way to set the value. say, value 1 = kill process at threshold #1 2 = kill process at threshold #2 (& not at #1) 3 = Only kill process if you're still running out of space after killing all you could kill at threshold's #1 and #2. 4 = if you're still running out of memory after #3, then just reboot, because it's hopeless... :-) To match the AIX behavior of SIGDANGER, the default would be #2. This gives the system administrator (or a generic user, for that matter) a way to specify the behavior on a per-process basis, and without having to recompile anything. Programs that wanted to could still provide their own handler, of course. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message