From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 9 10:10:34 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA41A16A41A for ; Wed, 9 Jan 2008 10:10:34 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from mail.beenic.net (mail.beenic.net [83.246.72.40]) by mx1.freebsd.org (Postfix) with ESMTP id 99B0F13C467 for ; Wed, 9 Jan 2008 10:10:34 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from [192.168.1.32] (a89-182-145-140.net-htp.de [89.182.145.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.beenic.net (Postfix) with ESMTP id D9722A44529 for ; Wed, 9 Jan 2008 11:03:36 +0100 (CET) From: "Heiko Wundram (Beenic)" Organization: Beenic Networks GmbH To: freebsd-hackers@freebsd.org Date: Wed, 9 Jan 2008 11:11:05 +0100 User-Agent: KMail/1.9.7 References: <67beabb0801081555v4ca3b729x294322fa724afa09@mail.gmail.com> <67beabb0801081925t67f995b8hc4cc779f88c2ba@mail.gmail.com> <66462bcb31fb347796200bd5260d7cdc@gmail.com> In-Reply-To: <66462bcb31fb347796200bd5260d7cdc@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801091111.06050.wundram@beenic.net> Subject: Re: Graceful failure instead of panicking in kmem_malloc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 10:10:34 -0000 Am Mittwoch, 9. Januar 2008 10:29:43 schrieb Joshua Isom: > Why not try to take out some user processes? Going with a combination > of process priority and memory usage, it should at least be more > tolerable than a panic. Ahemm. No. That's not tolerable in real world conditions. Have you ever had the OOM-killer strike on Linux (which is known for this, and has been criticized at other times for its braindead default behavior of overcommiting virtual memory space almost two-fold)? That's a major, major PITA. I'd rather have the system reboot and come back up to a clean and initialized state than to "randomly" kill user processes and leave it crippled but (somewhat) running (with sshd possibly killed off, which is especially bad on remote boxes), as basically to recover cleanly from the OOM-killer striking, you're going to have to reboot the box anyway. -- Heiko Wundram Product & Application Development