On Thu, 6 Jul 2000, Derek Martin wrote:
>Date: Thu, 6 Jul 2000 22:40:02 -0400 (EDT)
>From: Derek Martin <derek@cerberus.ne.mediaone.net>
>To: Marcelo Tosatti <marcelo@conectiva.com.br>
>Cc: Mike A. Harris <mharris@meteng.on.ca>,
> Linux Kernel mailing list <linux-kernel@vger.rutgers.edu>
>Subject: Re: Kernel 2.2.14 OOM killer strikes.
>
>On Thu, 6 Jul 2000, Marcelo Tosatti wrote:
>
>> If the kernel does not kill some processes (or one process) when the
>> system is under OOM, probably all the system will lockup because there is
>> no memory and no more swap space left. Your chance to start a shell and
>> kill the memory hog is gone.
>>
>> Now _which_ process(es) the kernel should choose to kill is a different
>> issue.
>
>Doesn't it make the most sense to kill the process that caused the OOM?
>That seems the most logical thing to me...
Me also, however consider this:
Process A which has went into lala land and is spinning out of
control keeps allocating memory. It fills all of memory, and
then all of a sudden a DIFFERENT process - say Netscape, needs a
half a meg. The overcommit would give netscape the memory, but
then when netscape USES it, the pages cannot be mapped, and the
kernel kills Netscape, meanwhile it was Process A which caused
the OOM condition 'logically'. That is the problem I believe, is
that the kernel needs to try and determine using logic which
process is the REAL bad guy. Next to impossible...
I'm dreaming up a daemon written in C for speed that:
1) Reads a config file of legal possible swapfile locations and
min/max sizes it can use, etc..
2) Has configurable high/low watermarks to determine when to
create new swap space.
3) Can monitor memory/swap usage on the fly every X number of
seconds (configurable), and if swap usage hits a certain high
water mark, the daemon can check disk space in the legal places
set forth by the config file, determine which (if any) locations
have enough space to create a swap file, and then creates a swap
file or files as quickly as possible (with nice -20) - possibly
even suspending other processes (configurable), then enables the
new swap file to handle the situation.
Such a daemon could be quite configureable to allow for many
different persons specific situations. I for example would
probably set it up so that it could make swap on any of 3
partitions I have, would not do so unless X amount of space was
available (to prevent filling up a partition and disturbing
something else), and would have it continue to monitor swap
usage. It could then determine if it needs to add more swap as
well later on, or determine if it could lose some of the swap. A
'low watermark' could determine when to sync a particular swap
file and swapoff it.
I wonder if anyone has done this at all? My solution is an
entirely userland approach, so kernel purists wouldn't have to
worry, however interested people could benefit.
Any takers? Probably wouldn't be that difficult to code.
Any ideas/suggestions welcome.
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocateI've overclocked my keyboard interface. It's quite messy dipping my hands into the mineral oil, but *MAN* is my keyboard ever fast now! - Anonymous Coward
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:20 EST