Date: Fri, 14 Mar 2003 14:03:23 -0300 From: "Daniel C. Sobral" <dcs@tcoip.com.br> To: Garance A Drosihn <drosih@rpi.edu> Cc: Juli Mallett <jmallett@FreeBSD.org>, Eivind Eklund <eivind@FreeBSD.org>, Mike Silbersack <silby@silby.com>, David Schultz <das@FreeBSD.org>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm ... SIGDANGER Message-ID: <3E720B5B.8090200@tcoip.com.br> In-Reply-To: <p05200f28ba97b4007dab@[128.113.24.47]> References: <200303122313.h2CNDHMU046431@repoman.freebsd.org> <20030312175458.J32334@odysseus.silby.com> <20030313005115.GA11794@HAL9000.homeunix.com> <20030313154226.X682@odysseus.silby.com> <20030314012954.A42430@FreeBSD.org> <20030314101857.A98861@FreeBSD.org> <p05200f28ba97b4007dab@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
Garance A Drosihn wrote:
>
> AIX (and maybe some other systems?) have a signal called SIGDANGER,
> which is meant for this kind of situation. If we implement some
> new signal, then perhaps it would be good to use that signal name
> and mimic their implementation of it.
Yes, SIGDANGER has the same default action as SIGTERM. If the
application installs a handler, fine. Otherwise, it dies. It sends such
signal when a threshold of some kind is reached, and it sends it to
every process (like our Notes server which always died after X hours,
before I realized that, by the time it died, it had allocated so much
memory there wasn't almost any memory left).
If the situation got worse, it would resort to killing the applications
anyway.
I seem to recall some care was taken that root could always login to
deal with situations were the above didn't help, but that's another matter.
> This has been talked about in the past, but has stalled out
> because there was "no room for new signals" (at the time).
> Something about a problem with adding any new signal number,
> although obviously I'm foggy on the details. And I don't know
> if that issue has been addressed in 5.0.
Yes, we had a limited number of bits available, and they were all used
up. Marcel, iirc, fixed this long ago.
> I would like to see this happen. No matter how much memory you have,
> it would be nice to have some kind of control over which processes
> will be killed when the system does run out of VM!
The problem is that everyone who knows enough to implement such feature,
so far, also thinks the real solution is to better dimension the resources.
There have been three suggestions to deal with low memory problem:
* First, one way of telling the kernel that a certain process should be
excluded from the processes that can be killed under low memory conditions.
* Second, SIGDANGER.
* Third, a sysctl to prevent overcommitting. With this on, memory would
be always immediatly allocated, instead of on-demand. With this, no
application would ever be killed. Either it aborted because it couldn't
allocate more memory, or it didn't. Since this can lock out users from a
machine, some of those that implemented this had a sort of reserve for
an interactive root process (which could still get exhausted, but whatever).
--
Daniel C. Sobral (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: Daniel.Capo@tco.net.br
Daniel.Sobral@tcoip.com.br
dcs@tcoip.com.br
Outros:
dcs@newsguy.com
dcs@freebsd.org
capo@notorious.bsdconspiracy.net
Reading is thinking with someone else's head instead of one's own.
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?3E720B5B.8090200>