From owner-freebsd-stable@FreeBSD.ORG Sat Mar 11 01:15:51 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 085D216A425 for ; Sat, 11 Mar 2006 01:15:51 +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 B2DFC44F24 for ; Fri, 10 Mar 2006 13:53:51 +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 k2ADrhmB072224; Fri, 10 Mar 2006 15:53:43 +0200 (EET) (envelope-from dmitry@atlantis.dp.ua) Date: Fri, 10 Mar 2006 15:53:43 +0200 (EET) From: Dmitry Pryanishnikov To: Kostik Belousov In-Reply-To: <20060310123942.GI37572@deviant.kiev.zoral.com.ua> Message-ID: <20060310153737.X40396@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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Michael Proto , freebsd-stable@freebsd.org, Peter Jeremy 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:15:51 -0000 Hello! On Fri, 10 Mar 2006, Kostik Belousov wrote: >> the largest RSS - it could e.g. be a vital part of the routing software >> (zebra/ripd/bgpd), and killing this process will render our router >> unreachable and unusable! > > Then, what should kernel do ? It kills the process because it _needs_ > the page. Usually, this page is needed to fill the frame that was already > allocated by some process, so, SIGKILL is another way to report ENOMEM. 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. Perhaps we should have possibility to choose between: 1) no process kills at all, just keep waiting until free memory gets available as a result of some other process's activity; 2) current algorithm; 3) kill the "youngest" process (with lowest runtime). > The only way to prevent this situation is to never satisfy > memory address range requests that (potentially) cannot be backed > by real memory (this includes swap) in the future. Compare "never satisfy request" and "kill another, totally unrelated, process". Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE