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>