From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 16:45:40 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A34AE16A4CE for ; Tue, 12 Apr 2005 16:45:40 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3481D43D1F for ; Tue, 12 Apr 2005 16:45:39 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j3CGja3Z095750; Tue, 12 Apr 2005 11:45:36 -0500 (CDT) (envelope-from dan) Date: Tue, 12 Apr 2005 11:45:36 -0500 From: Dan Nelson To: Nick Barnes Message-ID: <20050412164536.GB4842@dan.emsphone.com> References: <20050412142640.GB1570@stack.nl> <51621.1113318561@thrush.ravenbrook.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51621.1113318561@thrush.ravenbrook.com> X-OS: FreeBSD 5.4-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: Marc Olzheim cc: Vivek Khera cc: freebsd-stable@freebsd.org Subject: Re: kernel killing processes when out of swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 16:45:40 -0000 In the last episode (Apr 12), Nick Barnes said: > This is the well-known problem with my fantasy world in which the OS > doesn't overcommit any resources. All those programs are broken, but > it's too costly to fix them. If overcommit had been resisted more > effectively in the first place, those programs would have been > written properly. Another issue is things like shared libraries; without overcommit you need to reserve the file size * the number of processes mapping it, since you can't guarantee they won't touch every COW page handed to them. I think you can design a shlib scheme where you can map the libs RO; not sure if you would take a performance hit or if there are other considerations. There's a similar problem when large processes want to fork+exec something; for a fraction of a second you need to reserve 2x the process's space until the exec frees it. vfork solves that problem, at the expense of blocking the parent until the child's process is loaded. -- Dan Nelson dnelson@allantgroup.com