Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Mar 2006 15:53:43 +0200 (EET)
From:      Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        Michael Proto <mike@jellydonut.org>, freebsd-stable@freebsd.org, Peter Jeremy <peterjeremy@optushome.com.au>
Subject:   Re: RELENG_4 on flash disk and swap
Message-ID:  <20060310153737.X40396@atlantis.atlantis.dp.ua>
In-Reply-To: <20060310123942.GI37572@deviant.kiev.zoral.com.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>

next in thread | previous in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060310153737.X40396>