From owner-freebsd-current@FreeBSD.ORG Fri Oct 21 15:00:50 2005 Return-Path: X-Original-To: current@freebsd.org 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 9721C16A41F for ; Fri, 21 Oct 2005 15:00:50 +0000 (GMT) (envelope-from mi+kde@aldan.algebra.com) Received: from blue.virtual-estates.net (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C0BE43D45 for ; Fri, 21 Oct 2005 15:00:49 +0000 (GMT) (envelope-from mi+kde@aldan.algebra.com) Received: from blue.virtual-estates.net (blue [127.0.0.1]) by blue.virtual-estates.net (8.13.4/8.13.4) with ESMTP id j9LF0n01036616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Oct 2005 11:00:49 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by blue.virtual-estates.net (8.13.4/8.13.4/Submit) id j9LF0mW7036615 for current@freebsd.org; Fri, 21 Oct 2005 11:00:48 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) X-Authentication-Warning: blue.virtual-estates.net: mi set sender to mi+kde@aldan.algebra.com using -f From: Mikhail Teterin To: current@freebsd.org Date: Fri, 21 Oct 2005 11:00:48 -0400 User-Agent: KMail/1.8.2 X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" X-Mailman-Approved-At: Sat, 22 Oct 2005 12:09:44 +0000 Cc: Subject: Why page-in a SIGKILL-ed process? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 15:00:50 -0000 Hello! I just had a nasty experience. gvim went crazy and accumulated over 4Gb of virtual memory (I'm using amd64). My system slowed down quite a bit and I SIGKILL-ed the process. Despite my repeated SIGKILL-ing, the process did not go away for a few minutes. According to top, it's state during the ordeal was something like: 17850 mi 1 -16 0 4158M 1118M wdrain 1 0:06 6.10% vim The question is: Why bother with paged-out parts of the process, when it is already doomed by SIGKILL? Shouldn't the pagefault-handling be interrupted by the delivery of this (pseudo-)signal to ensure instant death without the disk-thrashing agony? -mi