From owner-freebsd-arch Tue Mar 25 9:22:31 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C63A437B401; Tue, 25 Mar 2003 09:22:27 -0800 (PST) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF33643FAF; Tue, 25 Mar 2003 09:22:16 -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 h2PHLf923653; Tue, 25 Mar 2003 14:21:41 -0300 Message-ID: <3E809024.1050303@tcoip.com.br> Date: Tue, 25 Mar 2003 14:21:40 -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: Poul-Henning Kamp Cc: David Schultz , Garance A Drosihn , Dan Nelson , Wes Peters , freebsd-arch@FreeBSD.ORG Subject: Re: Patch to protect process from pageout killing References: <14382.1048580753@critter.freebsd.dk> In-Reply-To: <14382.1048580753@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-19.2 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > If we are going to do this, we should do it right. > > Doing it right means that we should also be sharing enough information > with userland, so that userland can adapt. > > Take a simple example: It makes sense for a program like fsck to > use all the RAM it can get hold off as cache, but it does not make > sense for the cache to be paged out. > > As I see it, there is a need for several mechanisms: SIGDANGER actually takes care of two of these steps: > > 1. A mechanism to export to userland enough information about the > current RAM availability, so that phkmalloc and application > specific code can make intelligent choices before things go bad. > > 2. A mechanism to alert userland to the fact that things _have_ gone > bad. SIGDANGER is sent to processes at threshold #1, alerting them the situation has become serious. > 3. A mechanism to influence the "Who do we kill ?" decision once > things have gone from bad to worse. When the situation becomes so critical that the system cannot proceed without first killing something, it will only kill a process which has registered SIGDANGER if there are no other suitable process. -- 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 If you put your supper dish to your ear you can hear the sounds of a restaurant. -- Snoopy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message