From owner-freebsd-current  Thu Mar 13  8:41:28 2003
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id DF9AC37B401; Thu, 13 Mar 2003 08:41:27 -0800 (PST)
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 16BBA43FAF; Thu, 13 Mar 2003 08:41:27 -0800 (PST)
	(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: from khavrinen.lcs.mit.edu (localhost.ipv6.lcs.mit.edu [IPv6:::1])
	by khavrinen.lcs.mit.edu (8.12.8/8.12.8) with ESMTP id h2DGfPCd078540
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Mar 2003 11:41:26 -0500 (EST)
	(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.12.8/8.12.8/Submit) id h2DGfPOS078537;
	Thu, 13 Mar 2003 11:41:25 -0500 (EST)
	(envelope-from wollman)
Date: Thu, 13 Mar 2003 11:41:25 -0500 (EST)
From: Garrett Wollman <wollman@lcs.mit.edu>
Message-Id: <200303131641.h2DGfPOS078537@khavrinen.lcs.mit.edu>
To: David Schultz <das@FreeBSD.org>
Cc: current@FreeBSD.org
Subject: Re: cvs commit: src/sys/vm vm_map.c vm_map.h vm_pageout.c
In-Reply-To: <20030313005115.GA11794@HAL9000.homeunix.com>
References: <200303122313.h2CNDHMU046431@repoman.freebsd.org>
	<20030312175458.J32334@odysseus.silby.com>
	<20030313005115.GA11794@HAL9000.homeunix.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-current.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-current>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-current>
X-Loop: FreeBSD.ORG

<<On Wed, 12 Mar 2003 16:51:15 -0800, David Schultz <das@FreeBSD.org> said:

> A real problem is that a swapped out process' uarea has to be
> paged back in, even when no memory is available.  I don't think
> there's an easy way around that, given that you need the uarea and
> kernel stack to handle the signal.

But you don't, actually -- at least not to ``handle'' a SIGKILL.  In
that case, you should be able to simply destroy the process and free
whatever swap it has been allocated without ever giving it control.
So is the issue that we don't want to send SIGKILL too aggressively,
and send some other signal to give the process a chance to exit
gracefully?

-GAWollman


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message