Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Mar 2003 16:37:59 -0500
From:      Garance A Drosihn <drosih@rpi.edu>
To:        John Baldwin <jhb@FreeBSD.org>, Pawel Jakub Dawidek <nick@garage.freebsd.pl>
Cc:        cvs-all@FreeBSD.org, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, David Schultz <das@FreeBSD.org>, Eivind Eklund <eivind@FreeBSD.org>, Juli Mallett <jmallett@FreeBSD.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Mike Silbersack <silby@silby.com>, "Daniel C. Sobral" <dcs@tcoip.com.br>
Subject:   Re: cvs commit: src/sys/vm ... SIGDANGER
Message-ID:  <p05200f2dba97f542c912@[128.113.24.47]>
In-Reply-To: <XFMail.20030314160548.jhb@FreeBSD.org>
References:  <XFMail.20030314160548.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05200f2dba97f542c912>