From owner-cvs-src Fri Mar 14 9: 3:50 2003 Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD74137B401; Fri, 14 Mar 2003 09:03:45 -0800 (PST) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55E7A43FBF; Fri, 14 Mar 2003 09:03:39 -0800 (PST) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id h2EH3O932357; Fri, 14 Mar 2003 14:03:24 -0300 Message-ID: <3E720B5B.8090200@tcoip.com.br> Date: Fri, 14 Mar 2003 14:03:23 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030214 X-Accept-Language: en-us, en, pt-br, ja MIME-Version: 1.0 To: Garance A Drosihn Cc: Juli Mallett , Eivind Eklund , Mike Silbersack , David Schultz , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm ... SIGDANGER 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> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-cvs-src@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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-src" in the body of the message