lkml.org 
[lkml]   [2000]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectKernel 2.2.14 OOM killer strikes.
First time I've OOM'd my machine in AGES.  The offending process
was midnight commander. I had selected to "view" a file of 143Mb
in size. It came up no problem. I decided to view it in HEX,
and it decided that it needed to load all 143Mb into memory to do
that I guess. Nice algorithm.

Oh well, the linux kernel has an equally nice algorithm, called
the OOM killer a.k.a. "I'll make arbitrary guesses as to which
processes are important and what should be killed".

It decided to kill off Netscape Communicator of which I had at
least 15 windows open with stuff that was important, and that I
wanted to read, and do not have bookmarks for - or any way of
easily locating again. It also decided to kill off "kwm" my
window manager, which effectively killed X windows and all
running applications - WITH DATA UNSAVED.

However... The two Midnight Commander processes that I had
running, one of which was locked up from a FTP session that had
suffered from internet disconnection, and the second which was
the REAL offending process gobbling up memory by the bucketfull.

Here is what I got in my logs:

Jul 6 16:35:42 asdf kernel: VM: killing process kwm
Jul 6 16:35:46 asdf kernel: VM: killing process netscape-commun

Now here is my take on it all:

1) Midnight Commander is poorly designed - at least in my
opinion. Not completely as an application, just some of the
brain dead things that it does. I can't see why it needs to load
an entire file into memory in order to display it in HEX
mode. It has a buffer of data. To display it in text mode, it
just sends the data to the screen, likely via ncurses equiv of
printf et al. To display in HEX mode, it _could_ simply allocate
another screen sized buffer to translate the chars into hex
ASCII, and then dump to the screen. Seems much smarter than
loading a 200Mb file into memory. Thats just my rant though...

I know, I know... "Why don't you fix it then instead of
complaining".. Standard comment, with a standard answer...


2) The kernel OOM killing issue is never going to be solved
properly because it would have to be sentient to do so. So no
amount of argument/debate will yield the omnipotent killing
algorithm, and as such it will always suffer from doing the wrong
thing, and pissing people off.

Therefore, since some people WANT OOM killing to be done, and
others such as myself do NOT want it to be done, could someone in
the know of doing so, please make it a compile time or run time
tunable option? I'd like to tell my kernel "If an OOM condition
occurs, under absolutely *NO* circumstances are you to EVER kill
a running process".

I am *NOT* asking for this to be the default option, nor am I
asking that everyone else use it. I *FULLY* understand the need
to have a system like we have right now FOR SOME SYSTEMS, however
my system does not need it, and I suspect many other desktop
systems do not either. I'd rather have the application that is
hogging memory DIE than everything on my system by some
"smart" algorithm.

Why not have the kernel just write a couple hundred megs of
random data to the root filesystem and reboot when detecting
OOM? Sounds about as logical to me..

Then again, I just lost a bunch of work, so my current pissed off
opinion likely reflects that. Please keep that in mind while
flaming me with the wisdom of the current situation..

GRRR!!!!

Not trying to irk anyone, just letting off some steam.

Take care,
TTYL



--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate

I'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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.219 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site