lkml.org 
[lkml]   [2000]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler)

Your making the deadly assumption that all applications behave themselves
exactly the same all the time. Oops... netscape decided to freak out and
take up all your memory... guess its the admins fault. Oops... some
mod_perl script decided to freak out and an apache process decides to suck
all of your CPU and MEM.

Crap like this does happen. An example of this is a webboard package
called "Blackboard" consisting of various mod_perl scripts, apache, and
mysql. It is an educational online conferencing system being used in
conjunction with many college classes and thus is quite vital to the
campus.

Unfortunatly its buggy as hell and the memory sucking bug didn't pop up
until we were a couple weeks into classes and locked into the system. A
mod_perl script freaks out, the copy of apache goes nuts, and we get a
bunch of lovely out of memory related messages to the console. Its times
like these that an OOM killer like Rik's would be very useful. I feel
Rik's OOM backported to 2.2.x would do wonders for situation. After
playing with Rik's OOM system, I know it would do the right thing on this
system but unfortunatly 2.4.x isn't trustworthy yet....

Yes, the software is buggy and should be fixed. Do I have the power to
fix a broken commerical package that I'm locked into? No.

The point of an OOM killer is if all hell breaks loose and you have a
choice between a locked up system, a system thats slow as hell because its
spending all its time swapping, or a system that kills the offender and
gets back to buisness. I choose the third option. I can't think of any
situation (either on desktop or server) where a system lockup or panic due
to OOM would be acceptible w/ 2.4.x.


On Thu, 12 Oct 2000, Matthew Hawkins wrote:

>
> Heh.. now all we need is some smart-arse to make something similar to
> apply to the _entire_ VM subsystem, and both Rik and Andrea can be happy
> ;)
>
> Seriously, am I missing something obvious or is it far simpler just to
> keel over and die if the system goes OOM? I mean, seriously, if the
> administrator lets it get to that state then he/she/it deserves a dead
> system. It's akin to having your car run out of petrol - you don't
> start shooting passengers because their extra load made the engine chew
> more. You pack up your kitty and go to the nearest petrol station and
> buy more, plug it into the car then learn from the experience so this
> fringe case of it happening doesn't happen again. I don't really see
> much difference between a car going "OOP" and a computer going OOM.
> Should we start deleting files according to some randomly-chosen
> heueristic if a filesystem goes "OOS" ?
>
> --
> Matt
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
>

--------------------------------------------------------------
Bruce A. Locke
blocke@shivan.org

"The Internet views censorship as damage and routes around it"
www.eff.org www.peacefire.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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