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)

I've had to support an app running as a back-end to a webserver that would
malloc() different amounts of memory depending on user input, up to
multiple gigabytes of memory which vastly exceeded the 512k the machine
had as main memory. The app was a program that would scan genetic
sequence looking for 'repeats' in the sequence, and one sequence would
malloc a hundred megs while a similar sequence of the same size would
cause the algorithm to try to malloc over a gig. Part of the algorithm
was actually to simply try to malloc all the memory it could and if it ran
out, it would bump down the resolution that it was scanning with and try
again. And it would regularly push the machine into OOM and take it down
because daemons got killed long before the OOM killer got around to taking
out the process that was malloc()ing all the memory. On other machines
I'd set RLIMIT_DATA and my OOM problems went away, but on linux this
didn't work (and i wasn't comfortable enough with kernel sources back then
to manage to find RLIMIT_AS).

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" ?
>
>

-
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:41    [W:0.287 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site