From owner-freebsd-stable@FreeBSD.ORG Sat Mar 11 01:16:49 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 81A3216A423 for ; Sat, 11 Mar 2006 01:16:49 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B514E49965 for ; Fri, 10 Mar 2006 20:06:46 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k2AK6cBF031784; Fri, 10 Mar 2006 22:06:38 +0200 (EET) (envelope-from dmitry@atlantis.dp.ua) Date: Fri, 10 Mar 2006 22:06:38 +0200 (EET) From: Dmitry Pryanishnikov To: Peter Jeremy In-Reply-To: <20060310193248.GC688@turion.vk2pj.dyndns.org> Message-ID: <20060310215306.P83075@atlantis.atlantis.dp.ua> References: <20060302181625.I3905@atlantis.atlantis.dp.ua> <76FAD2DB-CD18-42D4-95C8-F016CFB17B00@segpub.com.au> <20060303110936.R86586@atlantis.atlantis.dp.ua> <20060303185157.GB692@turion.vk2pj.dyndns.org> <20060304001224.G356@atlantis.atlantis.dp.ua> <20060304065138.GD692@turion.vk2pj.dyndns.org> <20060310121758.S80837@atlantis.atlantis.dp.ua> <20060310123942.GI37572@deviant.kiev.zoral.com.ua> <20060310153737.X40396@atlantis.atlantis.dp.ua> <20060310193248.GC688@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , Michael Proto , freebsd-stable@freebsd.org Subject: Re: RELENG_4 on flash disk and swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2006 01:16:49 -0000 Hello! On Sat, 11 Mar 2006, Peter Jeremy wrote: >> But AFAIK the kernel kills NOT the requesting process but the one with the >> largest RSS. This selection algorithm seems to be the dumbest one, since >> process with largest RSS almost always is the process which does some real >> work. > > This frees up the greatest amount of memory and so minimises the risk > of the problem recurring. For OS yes, it's great to obtain a lot of free pages. But as I wrote in another post, if this process was e.g. bgpd, router becomes unusable and unreachable. So at this point OS benefit differs from system administrator benefit: for me, it would be better if that remote router paniced and rebooted instead of being up but non-operational. >> Compare "never satisfy request" and "kill another, totally unrelated, >> process". > > This has been argued about many times in the past - though not with > any satisfactory solution AFAIK. Look for 'SIGDANGER' in the archives. OK, I see, it's very difficult task to decide which process to kill. So I as an administrator want to have a tool to turn this process killing off. Of course I can (and will) patch OS kernel, but I'm sure that I'm not alone. That's why I've proposed some ideas in this area. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE