From owner-freebsd-stable@FreeBSD.ORG Tue Apr 12 18:16:58 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 D2FFA16A4CE for ; Tue, 12 Apr 2005 18:16:58 +0000 (GMT) Received: from luzifer.incubus.de (incubus.de [80.237.207.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1C1143D5E for ; Tue, 12 Apr 2005 18:16:57 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from drjekyll.mkbuelow.net (pD9542FFB.dip.t-dialin.net [217.84.47.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luzifer.incubus.de (Postfix) with ESMTP id 88D3F33788; Tue, 12 Apr 2005 20:16:38 +0200 (CEST) Received: from drjekyll.mkbuelow.net (mkb@localhost.mkbuelow.net [127.0.0.1]) by drjekyll.mkbuelow.net (8.13.3/8.13.3) with ESMTP id j3CIHWRT017619; Tue, 12 Apr 2005 20:17:33 +0200 (CEST) (envelope-from mkb@drjekyll.mkbuelow.net) Message-Id: <200504121817.j3CIHWRT017619@drjekyll.mkbuelow.net> To: Dan Nelson In-Reply-To: Message from Dan Nelson <20050412164536.GB4842@dan.emsphone.com> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 12 Apr 2005 20:17:32 +0200 From: Matthias Buelow cc: Marc Olzheim cc: freebsd-stable@freebsd.org cc: Vivek Khera 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 18:16:58 -0000 Dan Nelson writes: >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. Is that really problematic these days, with huge disk sizes? I mean, a couple GB swap don't really hurt anyone these days when you've got disk sizes around 250GB. Especially when you gain a lot more reliable operation through this. And maybe one could make overcommitting configurable, so that all scenarios are provided for. I for one would happily add some more swap space if I could get the behaviour that the OS doesn't go politician and promise all and everything which it then cannot deliver. Overcommitting made sense in the early 90ies, when you had a large address space (4GB) and relatively small disks (~1GB). I'm not sure it makes much sense anymore, it's a typical kludge. This stuff has been discussed in the past. It'll probably continue to be an issue, until it has been resolved satisfactorily (i.e., both the overcommitters and reliable-VMers can have their way). mkb.