From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 12 22:41:15 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D480716A4CF for ; Tue, 12 Apr 2005 22:41:15 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B26143D31 for ; Tue, 12 Apr 2005 22:41:15 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j3CMepbi020121; Tue, 12 Apr 2005 18:40:51 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j3CMepo3020120; Tue, 12 Apr 2005 18:40:51 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 12 Apr 2005 18:40:50 -0400 From: David Schultz To: Steven Hartland Message-ID: <20050412224050.GA20005@VARK.MIT.EDU> Mail-Followup-To: Steven Hartland , "Dag-Erling =?us-ascii:iso-8859-1?Q?Sm=F8rgrav?=" , ALeine , freebsd-hackers@FreeBSD.ORG References: <200504121224.j3CCOFXL019177@marlena.vvi.at> <011a01c53f66$4035aa00$b3db87d4@multiplay.co.uk> <86ll7ox7re.fsf@xps.des.no> <020201c53f82$e4b54330$b3db87d4@multiplay.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <020201c53f82$e4b54330$b3db87d4@multiplay.co.uk> cc: ALeine cc: "Dag-Erling =?us-ascii:iso-8859-1?Q?Sm=F8rgrav?=" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: kernel killing processes when out of swap X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 22:41:16 -0000 On Tue, Apr 12, 2005, Steven Hartland wrote: > ----- Original Message ----- > >There is no "large process detection". The first process that tries > >to fault in a new page after the system runs out of swap gets killed. > > That makes sense. Me trying to connect to see what was going > on would hence cause sshd to be killed ( not good ). > It would seem that we could do with doing something to prevent this. > We have had a few suggestions so far. > 1. Using madvise, requires code changes per app Using madvise doesn't require changes per app, since MADV_PROTECT is inherited across exec. You just have to write a wrapper, much in the spirit of nice(1), to execute a protected version of X. I agree that it's possible to do better, but this has already been discussed several times before, and whenever it comes up, there's always lots of noise because lots of people who don't understand deadlock chime in. If someone really wants to fix this in a reliable way, they need to go off and implement the necessary accounting in the VM system so that we don't overcommit swap. Most of the other suggestions, such as SIGDANGER, are just heuristics that might save your butt if you're lucky.