Messages in this thread | | | Date | Thu, 6 Jul 2000 16:54:42 -0400 (EDT) | From | "Mike A. Harris" <> | Subject | Kernel 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/
| |