lkml.org 
[lkml]   [2000]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel 2.2.14 OOM killer strikes.


Well, sometimes I don't care if the kernel kills some processes because of
a memory hog. But it should kill things like the hog itself or big
applications.
What I do *not* understand is why it hapilly kills system management
processes like syslogd, inetd or sendmail, when they don't use much memory
or CPU, making my machine useless.

It's trivial for any user to bring the system to an unusable state:

for(;;) malloc(1);

...and boom! In 15 seconds there's no more inetd, logins, http, etc :(

regards

Claudio Martins


On Thu, 6 Jul 2000, Mike A. Harris wrote:

> 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


-
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.126 / U:0.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site